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ABSTRACT 

Computer  viruses  have  threatened  the  integrity  and  reliability  of 
computer  systems  since  1983.  Literally  hundreds  of  viruses  exist  for  the 
IBM  compatible  computer  alone.  These  viruses  can  cause  corruption  or  loss 
of  program  and  data  files,  incidental  damage  to  hardware,  and  degradation 
or  loss  of  system   performance. 

This  paper  examines  the  nature  of  the  virus  threat  by  discussing 
virus  types,  methods  and  rates  of  propagation,  relative  frequencies  of 
occurrence,  and   genealogy. 

Possible  methods  for  virus  detection  and  identification,  followed  by 
disinfection,  are  outlined.  Minimum  capabilities  and  testing  criteria  for 
these   products  are  also   detailed. 

Methods  for  controlling  and  limiting  infection  and  damage  are 
discussed.  These  are  considered  minimum  acceptable  safeguards  to  be 
implemented   by  an  organization. 

Lastly,  software  authentication  means  are  examined,  which,  when  used 
in  conjunction  with  the  minimum  safeguards,  would  eliminate  the  possibility 
of  viral  infection. 


in 


t.i 


TABLE  OF  CONTENTS 

I.  INTRODUCTION 1 

A.  BACKGROUND 1 

B.  SOFTWARE  CATEGORIES   2 

C.  MICROCOMPUTER  RELIABILITY   3 

II.  NATURE  OF  THE  VIRUS  THREAT 5 

A.  NAME  ORIGIN 5 

B.  TYPES   OF   VIRUSES 5 

1.  Boot  Infectors     6 

2.  System  Infectors 7 

3.  Executable  Program  Infectors 7 

C.  PROPAGATION   ESTIMATES 9 

D.  RELATIVE   FREQUENCY 11 

E.  VIRAL   GENEALOGY      13 

III.  VIRUS   IDENTIFICATION  AND  REMOVAL     15 

A.  IDENTIFICATION 15 

1.  Infection  Preventers     16 

2.  Infection  Detectors     17 

3.  Infection  Identifiers 18 

B.  REMOVAL 19 

1.      Virus  Specific  Disinfectors 20 


IV 


2.       Universal  Disinfectors      20 

IV.  VIRUS   INFECTION   PREVENTION   METHODS     24 

A.  USER  TRAINING 24 

1.  Basic    Precautions      24 

2.  Virus   Recognition     25 

B.  HARDWARE   MEASURES      26 

1.  Write   Protect  Tabs      26 

2.  Tamper-proof  Shrinkwrap     27 

3.  CD   ROM      27 

C.  SOFTWARE   MEASURES      28 

1.  Virus  Scanners 28 

2.  Authentication   Methods 28 

V.  AUTHENTICATION   METHODS      31 

A.  CHECKSUMS      32 

B.  CYCLIC   REDUNDANCY  CODES       32 

C.  ENCRYPTION 34 

1.  Cryptographic   Systems 36 

2.  Reasons  for  Cryptography 37 

a.  Secrecy      37 

b.  Authenticity 37 

3.  Types  of  Cryptosystems     38 

a.  Symmetric  Cryptosystems 38 

b.  Asymmetric   Cryptosystems     38 

D.  MESSAGE  AUTHENTICATION   CODES 39 

v 


1.  Public  Key  Cryptosystems 39 

a.  Providing   Secre cy 40 

b.  Providing  Authentication     40 

c.  Secrecy  with  Authentication     40 

2.  Message   Digests 41 

a.  Hash   Functions 41 

b.  The   RSA   Signature   Scheme 42 

E.       HYBRID   SYSTEMS 43 

VI.  PRACTICAL   SOFTWARE  AUTHENTICATION      45 

A.  MD4 45 

B.  SIGN  AND   CHECK      46 

C.  VIRUS-SAFE 46 

VII.  CONCLUSIONS   AND   RECOMMENDATIONS 48 

A.  CONFIDENCE   BUILDING 48 

1.  User  Training      49 

2.  Virus   Detection  and  Removal 49 

B.  ASSURANCE   BUILDING     50 

1.       Software  Authentication      50 

C.  THE  BOTTOM   LINE      52 

VIII.  APPENDICES      54 

A.  EXAMPLES   OF  DOS   VIRAL   INFECTION  IN  THE   US      54 

B.  CHRONOLOGY  OF  A  VIRUS  AS   TOLD   BY  IT'S  AUTHOR    ....  55 

C.  KNOWN  VIRUS   INFECTION  AND   DAMAGE   CHARACTERISTICS    .  56 


VI 


D.  ANTI-VIRAL    PRODUCT   MINIMUM   CAPABILITIES    LIST      ....  60 

1.  Infection   Prevention   Products 60 

2.  Infection   Detection    Products 60 

3.  Infection   Identification   Products 61 

E.  ANTI-VIRAL    PRODUCT    EVALUATION    PROCEDURES      62 

1.  Infection   Prevention   Products 62 

2.  Infection   Detection    Products 63 

3.  Infection   Identification   Products 63 

F.  ANTI-VIRAL   SOFTWARE 65 

1.  Infection   Prevention   Systems 65 

2.  Infection   Detection   Systems 65 

3.  Infection   Identification   Systems 65 

G.  MD4   LISTING 66 

IX.        LIST   OF   REFERENCES       71 

INITIAL   DISTRIBUTION   LIST      73 


vn 


ACKN     ^LEDGEMENT 

I   would   like    to   give   special    thanks   to  the    following   individuals    who 
spent   their   time   discussing   the   subject  with   me. 


Mr.  Mike  McLaughlin  Navy  Information  Resources  Management 

Ms.  Judith  Froscher  Naval  Research  Laboratory 

Mr.  Bruce  Calkins  National  Computer  Security  Center 

Mr.  Bruce  Coster  National  Computer  Security  Center 

Dr.  Dennis  Branstad  National  Institute  of  Science  and  Technology 

Mr.  John  Wick  National  Institute  of  Science  and  Technology 


Thanks  to  Mr.  Kenneth  Van  Wyk,  moderator  of  the  VIRUS  DISCUSSION 
LIST,  for  sending   me  his  excellent  product. 

Very  special  thanks  to  my  advisor,  Dr.  Norman  F.  Schneidewind,  at  the 
Naval  Postgraduate  School,  Monterey,  CA,  and  my  second  reader,  Mr.  John 
Mildner,  at  the  Naval  Electronic  Systems  Security  Engineering  Center, 
Washington,  DC,  for  their  patience  and  efforts  to  help  me  complete  this 
research   project. 

This  research  was  supported,  in  part,  by  the  Naval  Electronic  Systems 
Security  Engineering  Center,  Washington,   DC. 


vm 


I.  INTRODUCTION 

A.        BACKGROUND 

Since  the  first  infectious  and  destructive  computer  virus  was  created 

1  , 

in  November    1983  ,  and   the   first  microcomputer   virus  in  January    1986", the 

i 
computer  security   field   has   never   been  the   same."    Computer   viruses   have 

received  wide  reporting  in  both  trade  journals  and  the  general  press.  Viral 

code  written   in    Asia  could   be    "exported",  via  modem   or   mail,  around    the 

world.    Systems  could  be  infected  quicker  than  warnings  could  be  received 

and   precautions  taken.     The   recent,  and   much   publicized,   UNIX   Worm  and 

AIDS   Trojan   incidents  are   but  two  examples  of  the   damage   malicious  code 

can   do. 


While  conducting  Doctoral  Thesis  research  at  the  University  of 
Southern  California  in  1983  and  1984,  Fred  Cohen  developed  the  first 
computer  virus  and  conducted  propagation  experiments  on  a  VAX  computer 
with  a  UNIX  operating   system. 

2 

The     virus,    later     named     Pakistani    Brain,    originated     in     Lahore, 

Pakistan.     It    was    developed     by     two  brothers     purportedly    as    a     copy 

protection    scheme    for    software    they  sold    in    their    store.    The    original 

version  of  this  virus   has    their  names  and   telephone  number    programmed 

in  the  code. 

For  comparison,  the  IBM  PC  was  announced  in  1980  and  went  on  sale 
October   1981. 

The  Pakistani  Brain  spread  rapidly  to  North  American  via  Europe. 
In  less  than  twelve  months  it  had  infected  nearly  a  half-million  computers 
in   hundreds  of  universities,  corporations  and   government  agencies. 

Cohen  conducted  five  trial  runs  in  which  his  virus  never  took  more 
than  an  hour  to  infect  the  VAX  system.  The  shortest  time  to  full  infection 
was  five  minutes,  the  average  half  an  hour.  His  work  was  so  successful 
that  university  officials   refused   to  allow  further  experiments. 


The  D  .artment  of  the  Navy  (DON),  in  its  drive  toward  technological 
sophistication,  is  becoming  increasingly  computer  dependant.  Ships  are 
receiving  administrative  microcomputers  and  "smart"  weapons  systems  while 
shore  establishments  have  their  management  information  systems 
interconnected  by  wide  and  local  area  networks  (WANS  and  LANS).  This 
dependency  and  interconnection  increases  the  potential  of  viral  infection 
and  the  threat  of  data  compromise  and  degradation  or  loss  of  system 
performance.  Regardless  of  the  source,  a  campus  prank s  **  or  a  foreign 
power,  protecting  our  systems  from  viruses  will  be  ess.  .lial  to  ensure 
their   reliability. 

B.        SOFTWARE  CATEGORIES 

Software  used  by  DOD  can  be  broadly  categorized  as  either  mission 
critical  or  mission  support.  Mission  critical  software  directly  impacts  on 
DOD's  ability  to  defend  the  United  States  from  attack.  Such  software  would 
include  missile  guidance  systems  and  military  forces  command  and  control 
programs.  Mission  support  software,  ill  other  DOD  software  not  di:  :tly 
effecting  the  defense  of  the  United  States,  would  include  payroll  packages, 
personnel  databases,  and  office  automation. 

Development  of  mission  critical  software  often  requires  access  to 
classified  hardware  design  and  performance  specifications.  Depending  upon 
classification,  special  storage  and  development  facilities,  access  t  icedures, 
and  testing  criteria  may  be  employed.  Additionally,  the  fielding  of  hardware 
and  software  systems  would  most  probably  be  performed  through  a  secure 
distribution  channel. 


Mission  support  software  development  will,  in  general,  require  access 
to  unclassified,  or  at  most,  unclassified  but  sensitive  data".  Many  of  the 
restrictions  for  classified  projects  may  not  apply.  Distribution  of  hardware 
and  software  will  be  through  the  Central  Design  Agent  (CDA),  the  standard 
supply  system  or  via  open  purchase.  Unfortunately,  this  increases  the 
vulnerability  of  our  systems  since  the  relative  percentage  of  word 
processors  procured  by  the  Navy  exceeds  the  number  of  missile  guidance 
programs. 

Due  to  the  comparatively  open  nature  of  development,  the  relative 
percentages  of  procurement,  and  the  underlying  simplicity  of  the  custody 
chain,   I  chose   to  examine  viral  protection  of  mission  support  software. 

C.        MICROCOMPUTER  RELIABILITY 

The  IBM  compatible  microcomputer's  popularity,  widespread  availability, 
and  general  lack  of  security  has  made  it  the  target  of  most  viral  attacks 
in  the  last  five  years.  The  threat  has  become  so  wide-spread  that  Allstate 
Insurance  Company  now  offers  virus  insurance.  Its  home  and  business 
insurance  policies  have  been  extended  to  cover  viral  damage  to 
microcomputers.  (Skulason,  1990,  #3-35)  These  are  the  same  systems  which 
have  been  used  aggressively  for  office  automation,  command  LANs,  and 
access  to  sensitive  command  and  control  systems  such  as  the  Worldwide 
Military  Command  and   Control  System   (WWMCCS). 


The  Computer  Security  Act  of  1987,  signed  into  law  8  January  1988, 
created  this  category  of  information.  It  includes  privacy  act  and  contract 
sensitive   data. 


With  this  in  mind,  I  will  focus  on  mission  support  software  for  IBM 
compatible  hardware  only.  Providing  viral  safeguards  for  these  systems 
is  a  first  step  toward  overall  computer  system  protection.  The  question 
then,   is   "How   do  we   provide   protection  from  viral  attack?". 

I  will  broadly  define  a  virus  as  any  program  which  replicates  and 
spreads   itself   secretly.   Assuming    a  given    computer  is    not  infected    when 

manufactured0,    the    infection    must    occur    during     use.    This    implies     the 

3  4 

infection   vector    is  the    software    which   is    then  added  to   it  by  the    user. 

We    can    then    narrow   our    research    question    to    "How    do    we    prevent    the 

loading  of  infected   software?". 

Before  answering,   we  must  understand  the   nature  of  the  threat,   the 

types  of  existing  viral  detection  and   removal  tools,  and   potential  means  of 

protecting    software.     These    issues    will    be    addressed    in    the    following 

chapters. 


This  is  not  unrealistic  since  the  vast  majority  of  microcomputers 
dedicated  to  mission  support  functions  are  IBM  compatible.  Indeed  many 
competitively  bid  procurement  contracts  have  specified  this  compatibility 
as  a  requirement. 

A  valid  assumption  since  memory  is  empty  and  any  disk  drives  are 
empty  or  unformatted. 

"An  agent  capable  of  transmitting  a  pathogen  from  one  organism  to 
another  either  mechanically  as  carrier  or  biologically  by  playing  a  specific 
role  in  the  life  cycle  of  the  pathogen."  [Webster's  Third  New  International 
Dictionary] 

Commercial,  shareware,  or  public  domain  only,  since  I  assume  a 
software  developer  will  not  write  code  to  deliberately  infect  and  damage  his 
own   system. 


II.   NATURE  OF  THE  VIRUS  THREAT 

A.  NAME  ORIGIN 

Virus  is  a  normal  Latin  2nd  declension  word  meaning  'slime',  'poison', 
and  'offensive'.  While  its  first  English  usage  was  in  1599,  it  was  not  used 
in  its  present  meaning  as  'filterable  virus  until  1880.  [Oxford  English 
Dictionary,  Second  Edition]  The  invisible  and  destructive  nature  of  the 
biological  virus  led  to  its  adoption  as  the  name  for  its  electronic  cousin. 
In  fact,  many  researchers  use  terms  reminiscent  of  the  biological  virus: 
vector,  infection  rate,  and  vaccine.  The  plural  of  'virus'  as  used  in 
English,   is   'viruses'.' 

B.  TYPES   OF   VIRUSES 

Computer  viruses  can  be  categorized  in  three  major  classes  based 
upon  their  area  of  system   residence  and/or  infection: 

•  boot  infectors 

•  system  infectors 

•  executable  program  infectors 


"An  infectious  organism,  usually  submicroscopic,  that  can  multiply 
inside  certain  living  host  cells.  A  non-cellular  structure  lacking  any 
intrinsic  metabolism  usually  comprising  a  DNA  or  RNA  core  inside  a  protein 
coating."  [Oxford  English  Dictionary,  Second  Edition]  It  would  pass  through 
filters  that  would   stop   bacteria. 

Of  note  is  the  significant  disagreement  between  academicians 
concerning  the  'true'  plural  of  'virus'.  The  first  quarter  of  1990  saw  weeks 
of  electronic  word  war  via  the  VIRUS  DISCUSSION  LIST  and  other  research 
oriented  electronic  forums  concerning  this  point.  For  my  part,  I  use 
'viruses'  throughout  this  work  to  represent  the   plural. 


1.       Boot  Infectors 

1  2 

These    viruses     reside     in    a    disk's      boot    sector.      If    active     in 

memory,  a  boot  virus  will   infect  a  new   disk    by   relocating   the   boot  sector 

contents   to  a  previously  empty   disk   sector  and   marking  it  as   bad    in   the 

File  Allocation   Table  (FAT).     The  virus  then  adds  a  jump  instruction  to  its 

end  and  writes  a  copy  of  itself  to  the   boot  sector.    The  jump  ensures  that, 

after  the   boot  virus    is  loaded   into  memory   and   executed   during    booting, 

computer  control  is  passed   to  the  original  boot  code  at  it's   new  location. 

An   infec4"         disk  can    infect  the    system  whenever    the   disk    boot 

sector  is    executed.     While    memory  resident,    these  viruses    can  infect   any 


'  DOS  disks  are  organized  using  a  rigid  scheme.  Each  disk  in  a  drive 
is  divided  into  one  or  more  logical  volumes.  Each  logical  volume  consists 
of  four  areas:  the  boot  sector  containing  configuration  and  bootstrap 
information,  an  original  and  backup  File  Allocation  Table  (FAT)  which  holds 
cluster  chaining  and  ownership  information,  the  disk  root  directory  which 
holds  information  pointing  to  the  first  cluster  in  the  FAT  chain  holding  a 
given  file's  or  subdirectory's  data,  and  the  file  area  which  consists  of 
clusters  maintaining  file  data  chained   by  the   FAT  pointers. 

The    boot    sector,    logical    sec  contains    critical    inf>       ation 

regarding  the  disk  medium  such  as:  S  iame  and  version,  bytes/ sector, 
sectors/cluster,  number  of  reserved  sectors,  number  of  FATs,  number  of 
root  directory  entries,  total  sectors  in  the  logical  volume,  media  descriptor 
byte,  number  of  sectors/track,  number  of  disk  drive  heads,  number  of 
hidden  sectors,  and  the  disk  bootstrap  to  load  the  operating  system  from 
disk  (the  ROM  bootstrap  is  smart  enough  to  home  the  disk  drive  head,  read 
the  boot  sector  from  disk,  and  jump  to  it  in  memory). 

The    "bad"    sector    marking    in    the    disk    FAT    ensures    that    these 
sectors  will  not  normally  be  examined  or  altered  by  the  system. 

Boot  infectors  typically  mark  several  "good"  disk  sectors  as  "bad". 
These  sectors  are  then  used  to  hold  the  original  boot  sector  code  plus 
whatever  virus  code  would  not  fit  in  the  boot  sector. 

A  disk's  boot  sector  is  examined  whenever  drive  hardware  detects 
a  diskette  change  or  upon  system  reset  for  logical  drive  0  only. 


disk  in  the  system.  These  viruses  are  fairly  tame  since  they  infect  a  given 
disk  only  once  and  are   relatively  easy  to  find. 

2.  System   Infectors 

These  viruses  attach  themselves  to  the  command  interpreter  and 
other  system  files  that  remain  memory  resident  and  reside  on  bootable  hard 
or  floppy  disks.'  Except  for  exclusively  targeting  system  files,  these 
viruses  behave  similarly  to  executable  program  infectors  which  are 
discussed   below. 

While  the  relatively  small  number  of  systems  programs  should 
make  these  viruses  somewhat  tame,  the  fact  that  systems  programs  remain 
memory  resident  and  are  frequently  called  allow  these  viruses  to  cause  a 
high   degree  of  infection   in  a  short  span  of  time. 

3.  Executable   Program   Infectors 

These  viruses  are  particularly  troublesome  since  they  can   spread 

2 
to    any     executable     program      in     the    system     by     either     appending     or 

overwriting.   A  virus  generally  appends  itself  to  either  the  front  or    back 

3 
end  of  an  executable  file.     Front  end  appenders   situate  their  code  so  it  is 


The  8086/8088  family  of  microprocessors  are  designed  so  that,  when 
reset  or  powered  up,  program  execution  begins  at  memory  address 
0FFFF0H.  This  lies  within  ROM  memory  and  contains  a  jump  instruction  to 
the  system  power  up  self  test  (POST)  and  bootstrap  code.  The  bootstrap 
code  loads  and  executes  the  system  programs  MSDOS.SYS  and  10. SYS. 
10. SYS  ultimately  loads  and  executes  the  command  interpreter 
C0MMAND.COM. 

Z    Any    program    ending    with    the    suffix    COM,    EXE,    OVL,    or    BIN    is 
considered   by  the  operating   system  to  be  executable. 

According  to  John  McAfee,  Chairman  of  the  Computer  Virus  Industry 
Association  (CVIA)  and  President  of  McAfee  Associates,  a  Santa  Clara, 
California  based  anti-viral   research  and   marketing   firm: 


e>  3uted  before  the  host  program.  After  the  virus  performs  3  task,  it 
then  returns  control  to  the  legitimate  code.  Back  end  appenders  usuallv 
add  a  JUMP  instruction  in  the  front  end  pointing  to  the  viral  code.  Aft 
virus  execution,  another  JUMP  points  back  to  the  original  program  code. 
Overwriting  viruses  simply  replace  a  section  of  the  existing  code  with  their 
own  instructions.  This  subgroup  is  usually  detectable  earlier  in  the 
infection  process  since  the  host  program  may  no  longer  function  correctly. 
The  appenders  may  slow  program  performance  but  will  generally  escape 
detection    ';ntil  the   virus   damage   sequence  is  triggered. 

This   type  virus   usually  accomplishes  its  infection   by  either: 


copying  itself  to  another  executable  file  whenever  an  infected  program 
is  executed  and  then  passing  control  to  the  host  program 

by   remaining    memory    resident  and    infecting   each    program   that    is 
loaded   into  memory 


During  infection,  the  original  file  size,  date,  and  time  may  be 
changed.  However,  sophisticated  viruses  may  save  and  restore  the  original 
values  when  writing  the  modification  to  disk.  Additionally,  to  avoid  early 
detection  and  maximize  infection,  the  virus  may  avoid   previ    asly  infected 


"Viruses  can  attach  to  a  program's  beginning,  end,  middle,  or  any 
combination  of  the  three.  They  may  fragment  and  scatter  virus 
segments  throughout  the  program  or  keep  the  main  body  of  the  virus 
unattached  to  the  program,  hidden  in  a  bad  sector.  All  known  viruses, 
however,  [modify  the  program's  beginning  to]  ensure  the  virus  is 
executed  before  the  host.  If  this  were  not  so,  the  uncertain 
environment  in  which  the  virus  executed  would  increase  the 
possibility  of  program  failure  [and  early  detection].  Viruses  which 
replace  entire  programs,  such  as  boot  infectors,  and  viruses  that 
attack  only  specific  programs  [such  as  system  infectors],  are  the  only 
exception  to  the  this  rule.  These  viruses  may  gain  control  at  any 
point,  since  the  structure  of  the  host  program  is  well  known  and  the 
environment  can   be  predicted."   (McAfee,   1989) 


files     or     delay     its     damage     sequence      until     infection     has     reached     a 
predetermined   level. 

C.        PROPAGATION   ESTIMATES 

Estimates  of  viral  multiplication  rates  are  not  easily  obtained  for  many 
reasons: 


computer  hardware  may  remain  constant  but  software  used  and 
preventative  measures  taken  may  vary  greatly  from  site  to  site  and 
machine   to   machine 

many  researchers  are  reluctant  to  divulge  their  estimations  since  they 
are  often  derived  from  reports  concerning  products  they  are 
supporting 

this   information   is   still  considered   'embarrassing'  and   'sensitive' 


Dr.  Fridrik  Skulason,  virus  researcher  at  the  University  of  Iceland, 
Technical  Editor  of  the  Virus  Bulletin  (UK),  and  consultant  to  the  Naval 
Computer  Incident  Response  Team  (NAVCIRT)  at  the  Naval  Electronic 
Systems  Security  Engineering  Center  (NAVELEXSECCEN)  in  Washington,  DC, 
has,  however,  recently  released  estimates  for  two  of  the  oldest  and  most 
wide-spread   viruses.     These  appear  in   Figure   1. 


Total  number  of  PCs  30.000.000  Machines 

Number  infected  with  Jerusalem      100.000-500.000  Machines 
Number  inf«ct«d  with  Brain  100.000-500.000  Machines 


Figure  1  -  Estimated  PCs  Infected  with  Jerusalem  and  Brain  (Skulason,  1990,  #3-64) 


The    Jerusalem   and    Pakistani    Brain    viruses    are   about    51    and    74 
months  old,   respectively. 


Figure  2  provides  the  amended  estimate  if  each  infection1  on  the  same 
machine   is  counted. 


Nu«ber  of  Jerusalem  infections      2.000.000-10.000.000  infections 
Number  of  Brain  infections         1.000.000-  5.000.000  infections 


Figure  2  -  EstiMted  Jerusalen  and  Brain  Infections  (Skulason,  1990,  #3-64) 

Of  note  is  the  apparent  virility  of  Jerusalem  compared  with  Brain 
even  though  Brain  is  a  third  older.  This  is  primarily  due  to  its  targeting 
of  executable  programs  instead  of  the  comparatively  rare  disk  boot 
se_  .ors. 

Skulason  hypothesizes  that  viral  infections  increase  exponentially  over 
time  but  slow  as  the  virus  saturates  the  system.  This  can  be  seen  in 
Figure  3.  His  experience  with  organizational  infections  indicates  that  once 
a  virus  infects  a  computer,  it  will  usually  spread  organization  wide  in  one 
to  two  months.   (Skulason,   1990,  #3-64). 


Skulason  estimates  that  20  infected  programs  reside  on  every 
Jerusalem  infected  machine,  and  10  diskettes  have  been  infected  by  every 
Brain  infected  computer. 

According  to  John  Mildner,  head  of  the  Naval  Computer  Incident 
Response  Team  (NAVCIRT)  at  the  Naval  Electronic  Systems  Security 
Engineering  Center  (NAVELEXSECCEN)  in  Washington,  DC:  "Jerusalem 
probably  spreads  more  rapidily  since  it  uses  executible  files  as  the 
infection  vector.  These  files  are  often  transfered  electronically  via  bulletin 
boards  or  computer  networks.  On  the  other  hand,  the  virus  most  common 
to  the  Navy,  the  Stoned  boot  sector  virus,  is  spread  by  exchange  of  data 
files  on  floppy  diskette."   (Mildner,   1991) 

Organizations  in  Iceland  are  not  that  large  -  The  Bank  of  Iceland 
is  one  of  the  largest  and  had  about  700  PCs  as  of  mid   1990. 
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Figure  3  -  Percentage  of  Organization  Infected  vs  Time  (Skulason,  1990B) 

Skulason  shows  that  the  number  of  infected  computers  will  rise  slowly 
when  the  virus  is  first  introduced,  but,  assuming  favorable  conditions  ,  a 
virus  will  infect  80%  of  the  machines  within  2  months.  The  virus  will  then 
probably  remain  unnoticed  for  some  time.  Once  detected,  it  is  usually 
removed  swiftly,  but,  almost  never  completely.  When  it  reappears  a  month 
or  two  later,  some  preventive  software  is  finally  installed  and  the  virus  is 
defeated.*  (Skulason,   1990,  #3-64) 

D.        RELATIVE   FREQUENCY 

A  virus's  frequency  of  occurrence  is  related  to  its  propagation  rate 
and  age.   Viruses  which   propagate  faster  such  as  executable   infectors  will 


Such  as  lack  of  preventive  hardware  or  software,  or  significant  disk 
or  program  traffic   between  different  computers. 

This  is  the  period  in  which  the  virus  actively  replicates  without  any 
noticeable  performance   degradation  or  damage   sequence. 

Particularly  if  backup  files  loaded  to  recover  lost  data  files  have 
been  corrupted. 

Skulason  estimates  that,  in  Iceland,  about  5%  of  all  PCs  have  been 
infected  with  a  virus.  However,  viewing  single  organizations,  he  either 
finds   no  viruses  or  an  80%  infection   rate. 
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be  seen  more  frequently  than  slower  propagators  like  boot  infectors. 
Likewise,  older  viruses  have  had  longer  to  establish  themselves  in  the  user 
community  and  will  be  spotted  more  frequently  than  viruses  which  have 
just  been  isolated.  Figure  4  lists  the  relative  frequency  of  viruses  as 
observed    by   David   Chess,   Fridrik   Skulason,   and   Morton   Swimmer. 
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figure  4  -  Observation  Frequencies  (Chess,  1990) (Skulason,  1990,  #3-91 ) (Swinner ,  1   1 ) 


These  figures  indicate  that  at  least  70  percent  of  the  infections  are 
caused  by  half  a  dozen  viruses.  As  of  February  1991,  222  major  virus 
strains  have  been  isolated.  Therefore,  more  than  70  percent  of  infections 
are  caused  by  less  than  3  percent  of  the  known  strains.  This  makes  the 
virus  identification  and  removal  problem  much  more  manageable. 


Joh  McAfee  identifies  10  viruses  (Pakistani  Brain,  Jerusalem, 
Alameda,  Cascade,  Ping  Pong,  Stoned,  Lehigh,  Den  Zuk,  Datacrime,  and  Fu 
Manchu)   which,   he   believes,   represent  95   percent  of  reported  infections. 
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Details  of  specific  infection  cases  in  the  United  States  are  provided 
in  Appendix  A  (McDonald,  1990).  A  chronology  of  the  Dark  Avenger  virus, 
as  told   by  its  author,  can  be   found  in   Appendix  B    (Skulason,  1990,   #3-97). 

E.        VIRAL   GENEALOGY 

As  the  number  of  viruses  increase,  so  does  the  difficulty  of  tracking 
their  inter-relations.  Figures  5  and  6  provide  the  genealogy  for  those 
viruses  considered   related   to  others. 


--several  minor  variants 

Golden  Gate 

SP 

Ashar 

--Brain some  minor  variants 

Clone 

Chaos 

Ohio 

--Den  Zuk 

Ping-Pong-- 

--a  number  of  minor  variants 

Big  Italian 

Ping-Pong  '286 

Typo 

Figure  5  -  Boot  Infectors  (Skulason,  1990,  #3-89) 


Like  its  biological  counterpart,  a  computer  virus  tends  to  evolve  and 
mutate.  This  mutation  is  controlled  by  programmers  who  generate  new 
viruses  from  the  source  or  disassembled  code  of  older  ones.  This  process 
often  precludes  major  changes  or  enhancements  and  may  assist  identifying 

new    viruses    soon   after    they   appear.     Appendix    C    (McAfee,    1991)    details 

i 
infection  and   damage  characteristics  for  known   IBM  compatible  viruses." 


A  recent  development,   however,  has  been  the   use  of  self  encryption 
to  hide  and  avoid   detection. 

2   As  of  26   February   1991. 
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III.      VIRUS    IDENTIFICATION   AND   REMOVAL 

A.        IDENTIFICATION 

Virus  identification  can  either  be  inadvertent  or  deliberate.  For  the 
average  PC  user,  viruses  are  unknown  or  something  that  infects  'others'. 
Either  way,  little  or  nothing  is  done  to  catch  infection  before  the  damage 
sequence  is  initiated.  Infection  is  inadvertently  discovered  when  the  virus 
triggers,   performs   its   destruction,  and   possibly   identifies   itself. 

Deliberate  identification  involves  the  active  use  of  various  software 
tools  tailored  to  locate,  identify,  and,  perhaps,  remove  viruses.  These  tools 
fall   into  three   major  categories: 

•  programs  which   prevent  infection 

•  programs   which   detect  infection  after  it  has  occurred 

•  programs  which   identify  pre-existing   infection 

John    McAfee,    Chairman   of   the    Computer   Virus    Industry    Association 

(CVIA)     and    President    of    McAfee    Associates",    a    Santa    Clara,     California 

based  anti-viral   research  and  marketing  firm,   points  out  that: 

"These    products,    however,    are    not   always   clearly    separable    in    the 
marketplace.  Some  combine  two  or  more  programs,  each  addressing   a 


CVIA  is  reputed  to  consist  of  95  percent  of  the  anti-viral  community. 
Most  of  the  members  are  vendors  of  anti-viral  products.  It  is  a  source  of 
anti-viral  programs  and  general  virus  information.  Additionally,  it  is  one 
of  the  few  groups  providing  cross  system  (IBM,  Macintosh,  etc)  information. 

McAfee  products  are  discussed  in  this  paper  for  illustrative 
purposes  only.  This  does  not  represent  endorsement  by  the  author  or  the 
Department  of  the  Navy.   They   represent  the  entire   product  spectrum. 
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single  protection  area,  into  a  single  package.  Others  may  focus  on  a 
single  type  of  protection  but  only  provide  a  partial  solution.  For 
example,  there  exist  infection  detection  products  that  will  only  detect 
changes  to  operating  system  files,  ignoring  all  other  executable  code." 
(McAfee,    1989) 

Minimum  capabilities  and  evaluation  procedures  for  these  tools  have 
been  defined  by  the  CVIA  and  are  listed  in  Appendix  D  and  E,  respectively 
(McAfee,  1989).  Appendix  F  lists  some  of  the  commonly  used  anti-viral 
products  and   their   vendors. 

1.       Infection   Preventors 

These  programs  normally  monitor  the  system  watching  for 
characteristic  viral  activities'.  If  detected,  they  suspend  activity,  alert  the 
user,  and  offer   to  terminate   the   suspect  program. 

The  primary  benefit  is  that  all  suspicious  activity  will  be  caught 
and  viruses  will  not  infect  the  system  or  spread.  This  means  that  strain 
identification  and  removal  is  not  required.  Conversely,  the  drawbacks 
include    numerous    interruptions    to    valid    programs     using    these    system 


Such    as    absolute    sector    disk    I/O,    disk    I/O    to    systems    files,    and 
altera     in  of  interrupt  vectors. 

'    With    the    exception    of    boot   infectors.    No    software    technique    can 
prevent  initial  infection  from  a  boot  virus. 

McAfee  believes  these  programs  require  a  user  with  a  "fair  amount 
of  technical  competence"  to  discriminate  between  legitimate  program  activity 
and  a     eal  virus  threat. 

"Some  applications  modify  their  executable  modules  during  the 
configuration  phase.  Compilers,  assemblers  and  linkage  editors 
legitimately  modify  or  replace  executable  code.  The  DOS  SYS  command 
will  legitimately  modify  the  boot  sector  and  operating  system  files. 
These  and  other  programs  may  cause  anti-viral  products  to  flag  the 
activity  and  notify  the  user.  The  user  must  have  sufficient  knowledge 
of  the  program  or  activity  in  process  to  determine  whether  to  allow 
it  to  proceed  or  to  terminate  it.  Many  system  users  do  not  have  the 
necessary  technical  depth  to  make  a  valid   decision"   (McAfee,   1989) 
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calls,    user    de-sensitization    due    to    false    positives  ,    and    reliance    on    the 
virus   being   'well  behaved'". 

These   products   should    be   tested,   prior   to   use,   to   determine   the 
degree  of  protection  afforded  executable  files  and  the  product's  sensitivity 
to  valid  activities   which   might  appear  suspicious. 
2.       Infection   Detectors 

Detection  products  operate  by  vaccination  or  status  logging. 
Vaccinators  modify  executable  code  to  include  a  self  test  module  which 
generates  a  run-time  warning  whenever  the  code  has  been  modified.  Status 
loggers  create  a  baseline  file  containing  key  file  information  (sizes,  dates, 
checksums,  etc.)  and  routinely  recheck  this  information  to  see  if  it  has 
changed.  If  a  modification  is  discovered,  a  warning  message  is  given  to 
indicate  the  areas  of  infection.  In  both  methods  the  key  assumption  is  that 
the  system  is   not  infected   prior  to  installation. 


If  the  product  flags  too  many  legitimate  activities,  the  user  becomes 
conditioned   to  respond  with   'continue'  without  reading  the  warning. 

The  assumption  that  viruses  perform  I/O  through  system  calls  or 
software  interrupts  is  reasonable  because  it  allows  execution  on  a  wide 
variety  of  hardware.  John  McAfee,  however,  notes  that  some  virus 
designers  are: 

"taking  the  extra  effort,  and  running  the  increased  risks,  of 
interfacing  directly  to  the  hardware  input/output  devices.  By  doing 
so,  they  completely  neutralize  the  infection  prevention  products' 
interrupt  monitoring.  No  matter  how  cleverly  software  interrupts  are 
trapped,  or  memory  monitored,  it  is  ineffectual  if  the  virus  never 
gives  up  processor  control  through  an  operating  system  call." 
(McAfee,   1989) 
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Advantages  include  checking  at  boot  time  instead  of  program 
execution  and  avoidance  of  interrupt  monitoring  .  Drawbacks  include  on 
line  baseline  file  maintenance  making  it  vulnerable  to  tampering,  the 
necessity  of  strain  identification  and  disinfection,  and  the  assumption  that 
the  system  is  infection  free  when  the  baseline  is  generated.  A  serious 
drawback  of  vaccination   products  is  that  they  can  not  detect  viruses   that 

replace  code  rather  than   modify  it  since  any  vaccination  code  would   never 

I 
have  an  opportunity  to  execute. 

Since    these    products    identif       infection   after    it    has    occurred, 

testing  should   be  conducted,   prior  to  use,  to  determine  if  they  can   detect 

modifications  to  executable  programs  such  as  the  boot  sector,  the  operating 

system,  or  an  application   program.  John  McAfee  explains  that: 

"Many  detection  products  use  the  virus  attachment  profile  to 
speed  system  checking.  If  every  byte  of  every  program  is 
processed  in  some  comparison  technique  global  checking  may  take 
some  time.  Systems  containing  many  hundreds  of  large  programs, 
may  require  anywhere  from  5  to  15  minutes  to  complete  the 
audit.  Since  a  global  scan  should  be  performed  at  least  daily, 
this  time  requirement  is  a  significant  nuisance  to  the  average 
user  and  a  deterrent  for  the  implementation  of  the  product. 
Products  that  only  look  for  the  characteristic  initial  instruction 
modifications,  on  the  other  hand,  would  complete  the  same  audit 
in  a  matter  of  seconds." (McAfee,   1989) 

3.       Infection  Identifiers 

Identification  products  scan  a  system  using  signature  byte  strings 
to     uniquely     identify     disk     or     file     infection    and     may    often     provide 


Regardless  of  a  virus's  sophistication,  some  executable  code  will  have 
changed  after  infection. 

j 

Boot    sector    viruses,    for    example,    replace    the    boot    sector    with 

themselves. 
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disinfection  and  recovery  assistance.  Their  primary  function,  however,  is 
identification. 

The  main  benefits  are  the  lack  of  assumptions  and  the  relative 
speed  of  execution.  The  main  drawback  is  the  almost  constant  stream  of 
new  product  releases"  required  as  new  viruses  are  isolated  and  old  ones 
mutate  . 

John  McAfee  describes  the  development  of  identification  products: 

"The  virus  must  first  be  discovered  and  isolated.  Then  it  must  be 
disassembled  and  analyzed.  Finally  an  effective  countermeasure  must 
be  designed,  implemented,  and  distributed  to  the  public.  The  time  lag 
for  this  process  is  a  few  months  to  a  year  or  more.  This  window  of 
opportunity  for  new  virus  developers  will  be  a  continuing  barrier  for 
such   products."    (McAfee,    1989) 

These    products    can    best    be     evaluated     by    their    success     at 

removing   an  actual  infection. 

B.        REMOVAL 

Fortunately  for  the  microcomputer  user  community,  if  viral  infection 
can  be  identified  prior  to  the  initiation  of  the  damage  sequence,  a  virus 
can  usually  be  removed  without  loss  of  data  or  program  files.  Two  general 
categories  of  disinfection   products  exist: 

•  products  which   remove  a  specific  virus  or   group  of  viruses 

•  products  which  remove  all  viruses 


They    can     determine    if    a    system    is    clean    prior    to    installing    a 
prevention  or  detection  product. 

McAfee  releases  a  new  version  of  VIRUSCAN  about  every  3   months. 

Viral  researchers  must  then  identify  a  signature  byte  string  which 
uniquely  identifies  it.  That  signature  string  must  be  included  in  the  next 
release  of  the  anti-viral  product. 
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1.       Virus  Specific  Disinfectors 

These  products  are  able  to  target  a  specific  virus  strain  or  group 

of    strains    for    removal.     They    are    often    included    with,   or   as    part   of,    a 

2 
detection  or  identification  product.     Authors  of  these   programs  frequently 

release   revisions  as   new  or   mutated   viruses  are  isolated. 

As  elsewhere,  terminology  is  a  point  of  contention  within  the  anti- 
virus industry.  With  luck,  the  following  terms  will  become  industry 
standards: 


signature  string:  a  uence  of    bytes  used  by  anti-viral  programs  to 

check   if  a  program         infected 

identification   string:   a    sequence  of  bytes    used   by  a      lrus  to   check 
if  a  program  is  infected 


2.       Universal  Disinfectors 

A  universal  virus  detector  and  disinfector  (UVD)  would  detect  and 
remove  viral  infections  both  known  and  unknown.  This,  of  course,  depends 
on  our  ability  to  define  viral  activity  under  all  circumstances. 

We  can  appreciate  the  probl^  by  refining  our  virus  definition. 
Fred  Cohen   defined  a  virus  as   "a  program  that  can  infect  other  programs 


As  of  February  1991,  217  major  virus  strains  exist.  If  modifications 
to  these  viruses  are  cour     d,  there  are  475  known  IBM  PC  viruses. 

McAfee's  VIRUSCAN  can  remove  many  of  the  most  common  viruses. 
The  disinfection  product  CLEANUP  is  also  provided  to  remove  all  viruses 
which  VIRUSCAN  is  capable  if  identifying. 

John  McAfee  releases  a  new  version  of  CLEANUP  about  every  3 
months. 

The  termt  have  been  defined  as  used  by  IBM,  -  itf  they  have  been 
used   interchangeably   by  other  researchers. 
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by    modifying    them    to    include    a    slightly   altered    copy   of    itself"     (Cohen, 
1984).   Unfortunately,   this   remains   valid   only   if   modernized   as   follows: 


"program"  should  also  include  boot  sectors,  INITs  and  all  other  forms 
of  executable  code 

"include"  must  also  cover  viruses  that  overwrite  the  victim  and  may 
destroy   it  completely 

"slightly  altered"  is  inaccurate.  One  can  imagine  a  virus'  that 
includes  only  a  part  of  itself  in  infected  programs  (Skulason,  1990, 
#3-24) 


Consider   Figure   7. 


Program  PI 

Display  ' 

This 

is 

a  copy 

utility" 

Display  ' 

Name 

of 

input  file  ?" 

Input  In- 

File 

Display  ' 

Name 

of 

output 

file  ?" 

Input  Out 

-Pile 

Copy  In-( 

ile  t 

o  Out-Pile 

End 

figure  7  -  Copy  Utility  Pseudo-Code  (Skulason,  1990,  #3-24) 


.   Skulason   details  a  program  with   three   parts: 

•  Part  A  contains  the   main   program 

•  Part  B  contains   program   locating  and   memory   residency   procedures 

•  Part  C  contains  I/O  routines. 

Assume  PI  contains  A+B  and  P2  contains  A+C.  Singularly,  since  they  are 
unable  to  replicate,  they  are  not  viruses.  When  executed,  PI  and  P2  will 
not  infect  other  programs.  PI  will  hide  B  in  memory  and  execute  the 
original  program.  P2  can  check  if  B  is  present  in  memory.  If  so,  A,  B  and 
C  are  combined  in  memory  and  executed.  This  new  program  uses  B  to  find 
more  programs  to  infect,  using  C,  with  A+B  or  A+C.  The  program  A,  B  and 
C  is  a  virus.  However,  it  includes  inert  code  instead  of  a  slightly  altered 
copy  of  itself  in  other  programs.  The  virus  only  activates  when  its  parts 
are  combined.    (Skulason,    1990,   #3-24) 
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If  we  tell  PI  the  input  fil  s  itself  and  some  existing  progr  an  is 
the  output  file,  PI  will  behave,  and  be  classified,  as  an  overwriting  virus.' 
PI,   however,  is   not  a  virus   since: 

•  It  asks   for  the   name  of  source  and   target  files;  and, 

•  It  destroys  the  victim   instead  of  executing   it     after  the  virus. 

Objection    2    may    not    be    valid,    however,    since   this    is    how    some    existing 
viruses  work.    (Skulason,   1990,  #3-24) 
Consider  Figure  8. 


Program  P2 

Display  "Naae  o 

f  output  file  ?" 

Input  Out-Pile 

Copy  P2  to  Out- 

Pile 

Knd 

Program  P3 

Display  "Naae  o 

f  input  file  ?" 

Input  In-Pile 

Select  Out-Pile 

at  random 

Copy  In-Pile  to 

Out-Pile 

End 

Prograa  P4 

Select  Out-Pile 

at  random 

Cop  ?4   to  Out- 

Pile 

2nd 

figure  8  -  Potential  Virus  Pseudo-Code  (Skulason,  1990,  #3-24) 

We  want  a  UVD  to  identify  P4  as  a  virus.   It  should  also  indicate 
that  P2  and  P3  might  be  virus  like  in  some  circumstances.   Unfortunately, 


As  well  as  most  operating  systems  since  they  'infect'  other  programs 
in  the  same  way.  A  compiler  used  to  compile  a  copy  of  itself  would  also 
qualify. 
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determining  those  circumstances   is  where  the   difficulty  arises.'    (Skulason, 
1990,  #3-24) 


Assuming  that  the  examined  program  and  it's  environment  are  of 
finite  size,  I/O  operations  transfer  finite  amounts  of  data,  and  the  UVD 
program  runs  on  a  different  machine,  a  UVD  may  be  possible  but  only  on 
a  machine  many  orders  of  magnitude  more  powerful  than  that  running  the 
examined  program.  If  the  first  is  a  Sinclair  ZX80,  with  IK  of  memory,  the 
second  would  need  to  be  more  powerful  than  all  current  super  computers 
combined.    (Skulason,   1990,  #3-24) 
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IV.        VIRUS   INFECTION   PREVENTION  ME^MODS 

Prevention  can   be   divided   into   three  areas: 

•  user   training 

•  hardware   measures 

•  software  measures 

A.        USER  TRAINING 

The  basic  building  block  of  security  is  user  training.  Hardware  and 
software  can  not  protect  a  user  from  himself.  A  solid  foundation  in  anti- 
viral measures  can  be  laid   by  a  two  step  training  program: 

•  basic  precautions 

•  virus  recognition 

1.       Basic  Precautions 

Most    viral    damage    can    be     easily    prevented     by    simple     user 
precautions: 

•  boot  only  from  write  protected  copies  of  the  distribution  diskette 

•  if  the  system  has  a  hard  disk,  never  boot  from  a  floppy  disk 

•  set  file  attributes  to  read  only  on  as  many  executable  files  as  possible 
to  help  prevent  spread  of  infection 
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•  consider  public  domain,  shareware,  and  borrowed  software  infected 
until  proven  clean 

•  watch  for  changes  in  system  activity  such  as  increased  disk  accesses, 
unusual  error  messages,  lost  disk  space,  disk  access  at  odd  time, 
decreased  available  memory,  slow  response,  or  unusual  screen  displays 
or  sounds 

•  in  a  network  environment,  load  proven  software  to  a  file  server  and 
set  file  attributes   to  read  only 

•  do   not  use   master/distribution   diskettes  as  working   diskettes 

•  keep  master/distribution  diskettes  in  a  safe  place,  away  from  the 
computer  working  area 

•  make  frequent  backups  of  changing   data  files 


2.       Virus  Recognition 

A  Virus  Simulation  Suite  is  available  to  mimic  the  visual  and 
audible  effects  of  the  most  common  microcomputer  viruses.  Like  their 
infectious  counterpart,  these  programs  are  terminate  and  stay  resident 
routines.  Unlike  the  real  virus,  however,  they  can  be  turned  on  and  off 
by  the  user  and  are  not  infectious.  Some  have  a  programmable  delay, 
usually  in  minutes,  to  simulate  the  replication  period.  Simulations  currently 
available  include: 


Actually,  the  same  holds  for  shrinkwrapped  commercial  software. 
Shrinkwrap  does  not  mean  virus  free.  It  is  most  frequently  used  in 
conjunction  with  the  licensing  language,  i.e.,  breaking  the  shrinkwrap 
means  agreement  with  the  terms  of  the  license.  Package  encapsulation  to 
reduce  the  risk  of  loss  or  contamination  and  increase  the  probability  that 
tampering   will  leave  evidence  is  an  incidental  benefit. 

The  Virus  Simulation  Suite  is  written  and  maintained  by  Joe  Hirst 
at  the  British  Computer  Virus  Research  Center,  12  Guildford  St,  Brighton, 
East  Sussex,   BN1   3LS,   England.   He  can   be  contacted  at  0273-26105. 
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•  Cascac 

•  Den   Zuk 

•  Fu   Manchu 

•  Ping   Pong 

•  Jerusalem 


These  simulations  could   help  develop  viral  activity  recognition   in 


users. 


B.        HARDWARE  MEASURES 

Virus  protection,  as  in  many  areas  of  computer  security,  may  be 
possible,  but,  certainly  not  foolproof,  without  hardware  assistance.  Many 
incidence  of  viral  infection  could  be  reduced  or  eliminated  by  the 
introduction  of  a  few  hardware  elements  of  varying  cost: 

•  write  protect  tabs 

•  tamper-proof  shrinkwrap 

•  CD   ROM 

1.      Write  Protect  Tabs 

These  devices  are  inexpensive  and  easy  to  use.  Most  computer 
systems,  and  certainly  those  manufactured  in  the  last  five  years,  implement 
disk  write  protection  in  hardware  vice  software.  Since  this  hardware 
inhibits  disk  writing  if  the  tab  is  in  place,  viruses  can  not  corrupt  a  write 
protected  disk.  Write  protect  tabs  should  be  on  all  floppies  put  in  a 
system. 


The  hard  drive  or  a  dedicated  flopp      :ould  then  be  used  for  output. 
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Original  distribution  diskettes  should  be  write  protected  as  soon  as 
removed  from  the  shrinkwrap  and  either  installed  on  the  hard  drive  or 
diskcopied  to  other  floppies   to   make  a  working  copy  of  the   software. 

2.  Tamper-proof  Shrinkwrap 

Unfortunately  for  the  buyer,  many  software  stores  have  the 
capability  to  re-shrinkwrap  software  which  has  been  purchased  and 
returned  or  used  for  showroom  demonstration.  While  this  makes  the  product 
once  again  available  for  sale,  it  does  nothing  to  protect  the  buyer  from 
diskettes  which  were  infected  by  the  machine  on  which  they  had  been 
previously  used.  To  preclude  this  unsuspected  hazard,  tamper-proof 
shrinkwrap,  perhaps  bearing  the  vendor's  corporate  logo,  could  be  used. 
Opening  and  resealing  of  software  could  be  immediately  determined  by 
inspection. 

3.  CD  ROM 

Since  systems  are  infected  by  using  infected  software,  the  most 
certain  means  of  preventing  infection  is  using  only  software  which  is 
certified  virus  free.  We  must  then  ensure  it  is  never  unintentionally 
modified.  One  method  is  the  exclusive  use  of  software  on  CD-ROM.  This 
optically  read  storage  medium,  while  much  slower  and  more  error  prone 
than  electrically  read  magnetic  media,  is  forever  inscribed  with  the  digital 
data  representing  program  and  data  files.  All  program  output  would  be 
directed  to  regular  magnetic  media-  The  drawback  is  the  prohibition  of 
user  software  customization. 


27 


C.       SOFTWARE  MEASURES 

The  last  software   method  for  combatting    viruses  includes  tuo   types 
of  measures: 

•  virus   scanners  which   search  for  viruses   in   memory  and  on   disk 

•  software  which  authenticates  user  software  prior  to  use  from  a  known 
true   baseline 

1.  Virus  Scanners 

Virus  scanners  are  programs  which  search  computer  memory  and 
disk  storage  looking  for  signature  byte  strings  characteristic  of  known 
viruses.   As   previously  discussed,  there  are  three  major  categories: 

•  programs  which  prevent  infection 

•  programs  which   detect  infection  after  it  occurs 

•  programs  which  detect  pre-existing  infection 

2.  Authentication  Methods 

Software,  both  commercial  or  government  produced,  is  shipped 
from  vendors  to  either  retailers  or  users.  While  undergoing  development, 
we  assume  that  it  is  protected.  However,  while  sitting  in  storage,  or  c .;  the 
user  system  itself,  we  consider  it  vulnerable.   (Spafford,   1990) 

Given  this,  we  may  develop  a  software  authentication  process 
consisting  of  the  following: 

•  the  vendor  generates  digitally  signed  software 

•  the  user  verifies  the  signed  software 

•  the  user  installs  and  customizes  the  software  on  his  system 

•  the  user  digitally  signs  his  installed  copy 
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•    the    user's    system    checks    the    executing    software    using     hardware 
and/or  software  authentication   methods   (Davida,    1989,   p   313) 


Hardware  is  generally  more  tamper  resistant  than  software.  The 
same  holds  true  for  hardware  based  authenticators.  The  actual 
authentication  method  used,  however,  will  be  decided  based  on  the  level  of 
security  (degree  of  trust)  required  and  the  dollars  available  for  procuring 
this   means. 

The  inherent  vulnerability  of  software  based  security  systems  is 
often  compensated  for  by  requiring  complex  access  procedures, 
sophisticated  self  verification,  or  booting  from  special  software  diskettes. 
Unfortunately,  this  may  be  more  than  the  average  user  will  religiously 
adhere  to.  Conversely,  complex  hardware  based  authentication  systems 
could  be  subverted  by  implanting  malicious  code  into  the  IC  chips  during 
the  design  process.  This  necessitates  testing  and  validation  of 
authentication  equipment  by  external  means.  Validation  testing  could  be 
eased   by   simple  authentication   hardware   design   since: 

•  chip  complexity  would   be  low 

•  chips    could    be    procured    from    multiple    sources    making    tampering 
impractical 

•  multiple  chip    design  would    require    the  malicious   code  to    be    spread 
across   devices  to  perform  its  task 

•  chips  older  than  computer  viruses  could  be  used  (Davida,  1989,  p  315) 


Acknowledging  this,  the  Department  of  Defense  has  recently  started 
work  on  its  own  semiconductor  plant.  This  plant  would  produce  "clean"  IC 
chips  for  use  in   sensitive  equipment. 
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The  key  problem  then  is  the  verification  of  the  verifying  means. 
A  possible  solution  is  the  use  of  cryptography  and  digital  signatures  to 
'sign'  a  software  package.  The  vendor  signs  his  release  or  update  and  the 
user  authenticates  the  signature.  Once  validated,  the  software  can  be 
installed,  customized  as  required,  and  'sealed'  by  the  user  using  his  own 
digital  signature. 

A  program  may  be  checked  when  installed  and  each  time  it  is 
executed.  The  question  of  authentic."4- ion  granularity,  like  the  hardware 
or  software  authentication  issue,  is  .ne  of  degree.  Determir  ion  of  the 
level  at  which  to  sign  an  executable,  i.e.,  program,  process,  or  instruction, 
is  a  function  of  the  degree  of  trust  required,  the  speed  of  the 
authentication  process,  the  size  of  the  executable,  and  the  method  used. 
(Davida,   1989,  p  317) 


A  complete  check  may  not  be  possible  if  segments  are  only  loaded 
as  needed.  In  timesharing  environments  a  process  is  at  risk  whenever  it 
doesn't  control  the  processor.  Events  such  as  paging,  segmentation,  or 
process  swapping  open  the  code  to  tampering.  Re-authentication  would  then 
be  required   prior  to  regaining  control. 
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V.  AUTHENTICATION   METHODS 

This  section  examines  the  theory  behind  several  software 
authentication  methods  broadly  categorized  as  "digital  signature" 
generators.  A  digital  signature  is  a  property,  private  to  a  user  or  process, 
that  is  used  for  signing  messages.  A  reliable  digital  signature  must  satisfy 
five   requirements: 


•  the  signature  must  be  unique  and  be  able  to  be  generated  only  by 
the  user 

•  it  must  be  computationally  infeasible  for  authentic  signatures  to  be 
generated   (forged)   by  unauthorized   users 

•  any  receiver  of  a  digitally  signed  message  (and  any  dispute 
arbitrator)  must  be  able  to  authenticate  the  signatures  authenticity 
even  after  a  considerable   period  of  time 

•  digital  signatories  must  not  be  able  to  deny  an  authorized  signature 
as  a  forgery 

•  digital  signatures  must  be  cheap  and  easy  to  generate  (Seberry,  1989, 
p   155) 


The     digital     signature,      since     it's      non-forgeable,     establishes      sender 
authenticity  equivalent  to  a  written   signature. 

This  work  advocates  implementation  of  initial  authentication  means  with 
the  least  delay  and  cost  possible.  Therefore,  the  following  methods,  ordered 
from  the  simple  to  the  complex,  were  reviewed  since  they  represented 
existing,  well  understood,  and  easily  implemented   technology.   They  are: 

•  checksums 

•  cyclic   redundancy  codes 

•  encryption 
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•  message  authentication  codes 

•  hybrid   systems 

A.  CHECKSUMS 

The  simplest  and  fastest  form  of  digital  signature  is  the  checksum. 
Checksums  treat  a  file  as  a  series  of  binary  numbers.  By  summing  all  the 
binary  numbers,  a  checksum  or  total  value  can  be  found.  Changes  to  files 
can  be  readily  determined   by  recalculating  the  checksum  and  c  iring   it 

with  the  previous   result. 

A  file  changed  by  a  virus  will  have  an  altered  checksum  unless  the 
virus  tries  to  compensate.  Unfortunately,  it  is  quite  easy  to  determine  a 
file's  stored  checksum  and  determine  an  additive  byte  string  which 
'corrects'  the  corrupted  file's  checksum.  Therefore,  checksums  do  not  meet 
requirement  2  for  reliable  digital  signatures  and  are  not  sufficiently  robust 
to  detect  changes  in  the  face  of  a  clever  attack. 

B.  CYCLIC  REDUNDANCY  CODES 

Most  commonly  used  for  error  detecting  during  data  transmission, 
polynomial  or  cyclic  redundancy  codes  (CRC)  can  be  used  to  detect  changes 
caused  by  viruses.  CRC  codes  are  generated  using  input  bit  strings  as  a 
representation  of  a  polynomial  with  coefficients  of  0  or  1.  A  n-bit  message 
or  message  segment  is  regarded  as  the  coefficient  list  for  a  polynomial  of 
degree  n-1  with  n  terms,  ranging  from  x1      to  x  . 


This  method  is  used  by  many  operating  systems  including  DOS  to 
determine  if  reads  and  writes  from  and  to  disk  have  been  performed 
correctly. 
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Polynomial  arithmetic  is  performed  modulo  2  and  is  functionally 
equivalent  to  an  exclusive  or  operation.  Long  division,  using  modulo  2 
subtraction,  can  only  be  performed  if  the  dividend  has  as  many  bits  as  the 
divisor. 

The  CRC  is  computed  by  first  selecting  a  generator  polynomial  of 
degree  r,  G(x),  with  at  least  the  high  and  low  order  bits  set  to  1.  Next, 
r  zero  bits  are  appended  to  the  low  order  end  of  the  n-bit  message  or 
message  segment  so  it  now  contains  n+r  bits  and  corresponds  to  the 
polynomial  x'M(x).  The  generator  bitstring  (the  coefficients  of  G(x))  is  then 
divided  into  this  new  bitstring  (the  coefficients  of  x:M(x))  using  modulo  2 
division.  The  remainder  is  then  subtracted  from  the  x'M(x)  bitstring  using 
modulo  2  subtraction.  This  resulting  bitstring,  polynomial  T(x),  is  the  new 
message  or  message  segment  which  is  then  sent.  Upon  receipt,  it  is  divided 
by  G(x).  If  a  remainder  exists,  a  transmission  error,  or  virus  corruption, 
has  occurred. 

Since  this  technique  is  more  sophisticated  than  a  checksum,  it  can 
detect  more  subtle  changes.  Checksums  rely  solely  on  addition  which  is 
insensitive  to    the   order   of  the    added    numbers    and  can    not    detect    byte 

swapping.   CRCs,    however,    can    detect    bit  and    byte    swapping    due    to    the 

2 
position   dependent  logic   used.     While    most  alterations  will   be  caught,    the 

CRC     method     will    not     detect    errors     or     corruptions    corresponding     to 

polynomials  containing  G(x)   as  a  factor.   If  G(x)  contains  two  or  more   terms 


Three    polynomials    have    become    international    standards    for    G(x): 
CRC-12,   CRC-16,  and   CRC-CCITT. 

CRCs    are    frequently    used    in    floppy    disk    controllers    in   order    to 
determine  whether  information   has   been  correctly  retrieved  from   disk. 
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(order  r  >1),  all  single  bit  errors  will  be  discovered.  By  making  x+1  a 
prime  factor  of  G(x),  we  can  catch  all  errors  consisting  of  an  odd  number 
of  inverted  bits.  Lastly,  a  CRC  code  with  r  check  bits  will  detect  all  burst 
errors  of  length  <=r.  Larger  bursts  have  a  (1/2)  probability  of  being 
unnoticed.    (Tannenbaum,    1989,   pp   210-211) 

The  bottom  line  is  that  requirement  2  for  reliable  digital  signatures 
is   not   met. 

C.        ENCRYPTION 

Cryptograph  se  ciphers  to  tra.  form  standard  f  aintext  messages 
into    secret    ciphertext    ones.     This     process,    called    encryption,    and     its 

reverse,  decryption,  are  controlled   by  one  or  more  cryptographic   devices 

s 

called   keys. 

Ciphers  are  typically  classified  in  one  of  two  general  types: 
transpositions  or  substitutions.  The  former  rearrange  data  bits  or  message 
characters  while  the  latter  replace  bits,  characters,  or  character  blocks 
with  previously  chosen  substitutes.  Most  computer  applications,  such  as  the 
National  Instit  e  of  Standards  and  Tec:  -ogy  (NIST)  Digital  Encryption 
Standard   (DES)   use  both  techniques  . 

Cryptoanalysis  is  the  science  of  cipher  breaking.  A  cipher  is 
breakable  if  it  is  possible  to  determine  either  the  plaintext  or  the  key  from 
the  ciphertext,  or  the  key  from  plaintext-ciphertext  pairs.  There  are  three 
basic  methods  used  for  attacking  ciphers: 


Often  implemented  in  a  combination  of  hardw?>       and   software. 
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•  ciphertext  only 

•  known   plaintext 

•  chosen   plaintext   (Denning,    1982,   pp  2-3) 

A  ciphertext  only  attack  requires  the  determination  of  the  key  solely 
from  intercepted  ciphertext,  knowledge  of  the  method  of  encryption, 
purloined  plaintext,  knowledge  of  the  ciphertext  subject  matter,  and  testing 
for  high  frequency  use  words.  The  known  plaintext  attack  method  uses 
knowledge  of  some  plaintext-ciphertext  pairs.'  Ciphers  should  be  accepted 
for  use  only  if  they  can  withstand  a  known  plaintext  attack  using  an 
arbitrary  number  of  plaintext-ciphertext  pairs.  The  last  method,  chosen 
plaintext  attack,  is  the  most  favorable  for  the  cryptoanalyst.  This  attack 
assumes  possession  of  the  ciphertext  corresponding  to  selected  plaintext. 
A  cipher  is  unconditionally  secure  if,  no  matter  how  much  ciphertext  is 
intercepted,  there  is  not  enough  information  to  determine  the  plaintext. 
(Denning,   1982,   pp   2-3) 

While  all  ciphers  are  breakable  given  unlimited  resources  and  time,  we 
need  not  develop  them  to  withstand  open-ended  attack.  A  cipher  which  is 
computationally  infeasible  to  break  will  suffice.  Computationally  secure 
ciphers  can  not  be  broken  by  systematic  analysis  with  reasonable 
resources  and  time. 


Encrypted  computer  source  programs  is  an  example.  The  ciphertext 
must  contain  certain  keywords  such  as  begin,  end,  loop,  if,  while,  read, 
write,  etc.  An  educated  guess  as  to  their  placement  can  be  made  and  the 
attack  begun.  The  same  can  be  done  with  the  executable  version  of  the 
software  if  the  equivalent  machine  instruction   byte  codes  are   known. 

Databases  have  been  identified  as  being  particularly  susceptible  to 
this  type  of  attack  if  users  can  insert  records  into  the  database  and  then 
observe  the  changes  in  the   stored  ciphertext. 
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1.       Cryptographic  Systems 

A  cryptographic   system   has   five  components: 

•  a  plaintext   message   space,   M 

•  a  ciphertext  message   space,  C 

•  a   key   space,   K 

•  a  family  of  encrypting   transformations,   E»:    M=>C 

•  a  family  of  decrypting  transformations,   D*:   C  =  >M   (Denning,  1982,   p   7) 

A  given  encrypting  or  decrypting  t:  sformation  is  defined  by  an 
algorithm  common  to  the  entire  'amily  but  using  an  unique  key.  For  a 
given  key  K,  the  decrypting  transformation  D,  is  the  inverse  of  the 
encrypting  transformation  E,,  such  that  D,  (E.(M))=M.  The  transformations 
Ejj  and  D,  are  described  by  parameters  called  the  encryption  key  and 
decryption   key,   respectively.    (Denning,   1982,   p  8) 

Cryptosystems   must  satisfy  three   general  conditions: 


the  encrypting  and  decrypting  transformations  must  be  efficient  for 
all  keys 

the  system   must  be  easy  to  use 

the  security  of  the  system  should  depend  only  on  the  secrecy  of  the 
keys  and  not  on  the  secrecy  of  the  algorithms  E  or  D  (Denning,  1982, 
P  8) 


The  first  requirement  is  essential  for  a  computer  based  application 
since  data  encryption  and  decryption,  usually  performed  at  transmission 
time,  must  not  be  a  bottleneck.  The  second  requirement  implies  it  must  be 
easy  for  the  cryptographer  to  find  a  key  with  an  invertible  transformation. 
The    last   requirement   implies    that   it   should    not    be    possible   to    break    a 
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cipher  simply  by  knowing   the  method  of  encryption  or  the  algorithm   used. 
(Denning,   1982,   p  8) 

2.       Reasons   for  Cryptography 

There  are   two   basic    reasons   for   using  cryptographic   systems: 

•  secrecy 

•  authentication 

a-       Secrecy 

Secrecy     requires     that     plaintext     data     be     impossible     to 
determine   from  intercepted  ciphertext: 


it  should  be  computationally  infeasible  to  determine  the  decrypting 
transformation  D,  from  intercepted  ciphertext  C,  even  if  the 
corresponding   plaintext  M   is   known 

it  should  be  computationally  infeasible  to  determine  plaintext  M  from 
intercepted   ciphertext  C   (Denning,   1982,   p  9) 


Secrecy,   therefore,   requires  only  that  the   transformation   D, 
(the   decryption   key)   be   protected.    (Denning,   1982,   p  9) 
b.      A  u  then  ticity 

Authenticity   requires    that   a  false   ciphertext   C  can    not    be 
substituted  for  a  ciphertext  C   without  detection: 


•  it  should  be  computationally  infeasible  to  determine  the  encrypting 
transformation  E.  given  C,  even  if  the  corresponding  plaintext  message 
M  is   known 

•  it  should  be  computationally  infeasible  to  find  C  such  that  D.(C')  is 
valid   plaintext  in  the   set  M   (Denning,   1982,   p  9) 
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Authenticity,  therefore,  requires  only  that  the  transf     mation 
E.    (the  encryption   key)    be   protected.    (Denning,    1982,   p  9) 
3.       Types  of  Cryptosystems 

Cryptosystems  can   be   placed   into  two   broad   classes: 

•  symmetric 

•  asymmetric 

a.  Symmetric  Cryptosystems 

These    systems    are    also    called    one-key  :eras    since    the 

encrypting  and  decrypting  keys  are  the  same  or  easily  derived  from  each 
other.  If  both  E.  and  D,  are  protected,  both  secrecy  and  authenticity  are 
ensured.  Secrecy  can  not  be  separated  from  authenticity  since  making 
either  E,  or  D,  public  exposes  the  other.  Therefore,  all  the  requirements 
for  secrecy  and  authenticity  must  hold  in  one-key  systems.  (Denning,  1982, 
P   10) 

b.  Asymmetric  Cryptosystems 

T  ese  systems  are  also  called  two-key  systems  with  E.  and 
D.  such  that  it  is  computationally  infeasible  to  determine  one  key  from 
knowledge  of  the  other.  In  another  sense,  E.  and  D.  may  be  thought  of  as 
one-way  functions  since  they  are  easy  to  compute  but  computationally 
infeasible  to   invert.     This   allows   publication   of   one    without   endangering 


the    other.    EL    is    protected    for    authenticity,    while    protecting    D.     wou 


Id 


This   means  its  very  difficult  to   determine  a  pla  ^.text  message  from 
the  ciphertext. 
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ensure  secrecy.  This  duality  makes  these  cryptosystems  ideally  suited   for 
creating   digital  signatures.    (Denning,    1982,   p    11) 

D.        MESSAGE  AUTHENTICATION   CODES 

Although  these  functions  use  cryptographic  means  to  create  a  message 
authentication  code  (MAC),  I  will  discuss  them  separately  from 
cryptosystems.  These  ciphers  are  primarily  used  in  applications  where  the 
need  is  not  the  decryption  of  transmitted  data  but  the  determination  of  a 
correspondence  between  a  message  M  and  ciphertext  C.  This 
correspondence  is  tested  by  encrypting  M  and  comparing  the  result  with 
C.     Several  types  of  MAC   systems  exist.   I   will  examine   the  following: 

•  public   keys  cryptosystems 

•  message   digests 

1.       Public  Key  Cryptosystems 

The  public  key  system,  an  asymmetric  cryptosystem,  allows  two 
users  to  hold  both  a  public  and  private  key  and  communicate  with  each 
other  knowing  only  the  others   public   key. 

User  A  has  a  public  encrypting  transformation  (key)  E.  which  may 
be  widely  known,  and  a  private  decrypting  transformation  (key)  D,  which 
is  known  only  to  him.  While  the  public  key  is  derived  from  the  private  key 
by  a  one-way  transformation,  it  is  computationally  infeasible  to  find  D.    (or 


Computer  logon  passwords  may  be  encrypted  in  this  method.  Since 
they  can  not  be  decrypted,  they  are  secure.  Yet,  when  a  user  enters  his 
password  at  logon  time,  the  transformation  is  applied  and  the  encrypted 
logon  password  is  compared  with  the  stored  encrypted  true  password.  If 
they  match,  logon   is  achieved. 
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its    equivalent)    from    it.    It    is    possible    to   apply    these    transformations    or 
keys   to  ensure   three   different  outcomes: 

•  secrecy 

•  authenticity 

•  secrecy   with  authenticity   (Denning,   1982,   pp    11-12) 

a.  Providing  Secrecy 

If  A  wishes  to  send  B  a  message,  and  knows  B's  public  key 
Eg,  he  can  transmit  M  to  B  in  secrecy  by  sending  the  ciphertext  C  =  EJM). 
On  receipt,  B  decrypts  C  using  his  private  key  Dg  getting  the  plaintext 
message  M  =  Dn(C)  =  Dn(En(M)).  While  this  process  provides  secrecy,  it  does 
not  provide  authentication  since  any  user  with  access  to  B's  public  key 
could  send  a  message  to  A  or  replace  one  with  his  own.  (Denning,  1982,  p 
12) 

b.  Providing  Authentication 

For  authentication,  M  must  be  transformed  using  A's  private 
key  C  =  D.(M).  On  receipt,  B  uses  A's  public  key  M  =  EA(C)  =  EA(DA(M). 
Authenticity  is  provided  since  only  A  can  apply  the  private  key. 
Unfortunately,  secrecy  is  not  provided  since  anyone  with  access  to  the 
public   key  can  obtain  the  plaintext.    (Denning,   1982,  p   12) 

c.  Secrecy  with  Authentication 

To  achieve  both  secrecy  and  authentication,  A  and  B  must  apply 
both  sets  of  transformations.  A  first  applies  his  private  key  on  M  to  assure 
authenticity  C  =  D.(M).  He  then  encrypts  this  with  B's  public  key  to 
provide  secrecy  C   =  Ej(C')   =   E^Dk(M)).    (Denning,   1982,  p   13) 
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2.       Message  Digests 

The  public  key  system  can  generate  a  digital  signature  by  using 
the  sender's  private  key.  This  results  in  a  signed  message  which  is, 
however,  twice  the  size  of  the  original.  To  alleviate  this,  most  techniques 
make  use  of  data  compression  before  forming  the  signature.  Here,  we  take 
a  N  bit  message  and  break  it  up  into  units  of  n  bits  (where  n  <<  \T).  The 
transformation  is  then  applied  to  each  of  these  units  with  the  results 
combined  to  form  a  signature  of  n  bits  called  a  message  digest.  The  key 
is  ensuring  that  computing  identical  digests  for  two  different  messages  is 
computationally   infeasible.    (Seberry,   1989,   p   156) 

Two   message   digest   generator   methodologies   follow: 

•  hash   functions 

•  the  RSA  Signature   Scheme 

a.       Hash   Functions 

These  are  one-way  functions  which  take  variable  size  input 
strings  and  return  a  fixed  size  unique  output  string.  The  primary  use  of 
hash  functions  is  to  determine  if  there  have  been  any  changes  made  to  a 
file. 

Application  of  one-way  function  F  on  a  plaintext  message  M 
yields  a  fixed  size  hash  code  H  =  F(M).  If  M  is  an  executable  program  file, 
H«  =  F(M)  is  its  hash  code.  If  M  is  altered  in  any  way,  a  new  hash  code, 
H  =  F(M'),  will  result.  Thus,  tampering  can  be  detected  by  comparing  the 
new  hash   with   the   previously  computed,  and   presumably  correct,  one. 
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The  property  of  one-way  hash  functions  allowing  their  use 
for  authentication  is  the  computational  infeasibility  of  finding  a  secon  ; 
message  M'  that  will  generate  the  same  hash  code  H  as  the  original  message 
M.  Because  of  this,  a  relatively  small  H,  128  to  256  bits  in  length,  can  be 
used   to  authenticate   very   large   files.    (Merkle,    1989A) 

Formally,  secure  one-way  hash  functions  have  four  properties: 

•  F   can   be  applied   to  an   M   of  any  size 

•  F   produces  a  fixed   size   H 

•  given   F  and   M,   it  is  easy  to  compute  H   =   I 

•  given   F,   it  is  computationally  infeasible  to  find  a  different  input  M\ 
such   that  M   <>   M'  and   F(M)   =   F(M')    (Merkle,   1989B) 

Since  practical  application  requires  a  known  input  size,  the 
hash  code  is  normally  developed  in  two  steps.  First,  function  F?  is  defined. 
It  is  similar  to  F  but  accepts  only  fixed  size  inputs.  Fn  is  used  repeatedly 
to  construct  F  via  bitwise  concatenation.  All  properties  of  F  hold  for  F7 
with  the  exception  of  the  fixed  input  size.  D  'cing  M  given  H  is  now 
equivalent  to  dete.  ning  the.  key  given  the  p  text  and  the  ciphertext. 
(Merkle,   1989B) 

b.       The  RSA  Signature  Scheme 

The  RSA  scheme  uses  both  the  public  key  cryptosystem  and 
data  compression  to  form  a  digital  signature.  Assuming  A  wishes  to  send 
B  a  signed  message  M,  he  first  shortens  it  using  compression  to  arrive  at 
the    message    digest    Mn    =    F(M).    Next,    A    encrypts    the    digest    using    his 


Named    as    a    supported    algorithm    in    the    NIST/'     I    Implementor's 
Workshop  Agreements  of  Dec   1989. 
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private  key  to  obtain  the  signature  M»  =  Di^J  =  D^(F(M)).  The  message  and 
signature  pair   (M  and   M<, )   are   then   forwarded   to   B. 

On  receipt  of  M  and  NL,  B  reproduces  the  message  digest  by  two 
different  methods.  First,  the  digest  is  recreated  from  the  signature  by 
applying  A's  public  key  Mr,  =  E^Mg).  Then  B  produces  his  own  copy  of  the 
digest  using  the  compression  function  (since  it's  public).  If  the  digest 
obtained  from  A's  signature  equals  the  digest  B  created,  the  signed  M  is 
accepted  as  authentic. 

E.        HYBRID   SYSTEMS 

These  systems  generally  use  a  combination  of  methodologies  to  optimize 
the  speed  of  computer  processing  versus  level  of  trust.  For  example,  a  DES 
based  system  makes  major  demands  on  a  personal  computer  due  to  the 
complex  mathematics  required  for  encryption.  In  order  to  speed  the 
processing  from  the  user's  viewpoint,  a  hybrid  mixture  of  DES  and  CRC, 
or  other  means,  may  be  used.  This  usually  results  in  a  small  percentage 
of  a  file  being  examined  with  a  sophisticated  MAC,  and  the  remainder 
examined  with  a  high  speed  CRC  algorithm.  Sophisticated  cryptographic 
techniques  are  used  to  assure  that  attackers  can  not  predict  which  bytes 
are  examined  by  each  method.  Additionally,  results  of  all  cryptographic 
calculations    are    carried    forward    into    all    subsequent    calculations.     This 


In    fact,    actual    bit     manipulation     is     most    often     implemented     in 
hardware  for  both   speed  and   security  concerns. 

"    Perhaps    the    portion    examined    by    the    MAC     would    be    the    code 
sections   most  frequently   modified   by  viruses. 
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results  in  a  digital   signature  that  is   faster  than  a  DES   MAC  and   stronger 
than  a  CRC.    (Bosen,   1989,   pp   7-9) 
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VI.        PRACTICAL   SOFTWARE   AUTHENTICATION 

This  section  examines  several  commercially  available  products  which 
make   practical   use  of  the   theory   previously   discussed. 

•  RSA's   MD4   algorithm 

•  RSA's   CHECK  and   SIGN   programs 

•  Enigma   Logic's   VIRUS-SAFE 

A.        MD4 

This  package,  programmed  and  maintained  by  Ronald  Rivest  of  RSA 
Data  Security,  has  been  placed  in  the  public  domain  for  review  and 
possible  adoption  as  a  standard.1  MD4  inputs  a  message  of  arbitrary  length 
and   produces  a   128  or  256   bit  message   digest. 

It  is  considered  computationally  infeasible  to  produce  two  messages 
having  the  same  message  digest,  or  any  message  having  a  specified  target 
message  digest."  Although  MD4  is  relatively  new,  the  security  provided 
should  be  sufficient,  for  implementing  very  high  security  hybrid  digital 
signature  schemes  based  on  MD4  and  a  public-key  cryptosystem.  (Rivest, 
1990) 


As  have  been  the  two  previous  MD  family  algorithms  MD2  and  MP3. 
These  were  circulated  throughout  the  industry  as  INTERNET  RFC  1113  and 
1114.   MD4   has   been   distributed  as   RFC    1115. 

RSA  conjectures  the  difficulty  of  deriving  two  messages  having  the 
same  message  digest  is  on  the  order  of  2  operations,  and  that  of  any 
message  having  a  given   message  digest  is  on   the  order  of  2"      operations. 
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The  C  version  of  the  MD4  algorithm,  listed  in  Appendix  G,  is  coded  for 
a  32-bit  word/8-bit  byte  machine  and  runs  at  1450,  70,  and  32  kBytes  per 
second  on  a  SUN  Sparc  station,  DEC  MicroVax  II,  and  20MHz  80286, 
respectively.    (Rivest,    1990) 

B.  SIGN  AND   CHECK 

RSA  Sign  &  Check  are  two  programs  which  allow  users  to  sign  files 
with  non-forgeable  digital  signatures  and  to  che<-  t.  given  signature's 
validity.  These  signatures  are  based  on  the  highly  t  ted  RSA  public  key 
cryptosystem  whic:  las  withstood  intensive  mission  critical  commercial  use 
as  well  as  fourteen  years  of  vigorous  challenge  from  the  academic  and 
scientific  communities. 

C.  VIRUS-SAFE 

This   product  relies  on   three   different  methods  for   producing   MACs: 

•  cyclic   redundancy  codes 

•  American  National  Standards   Institute   (ANSI)   standard  X9.9^ 

•  International  Standards  Organizat      .   (ISO)   standard  8731-^ 

VIRUS  SAFE  allows  several  methods  of  operation  to  optimize  security 
versus   performance.     The  frequency  and   thoroughness  of  file  examination 


ANSI  X9.9    describes  a  way  of    using   DES   to   calculate  a  MAC    which 
is  believed   impossible  to  forge. 

ISO  8731-2  is  currently  used  in  the  international  banking  community 
to  authenticate  funds  transfer. 

i 

The    thoroughness    of    file    examination    which    makes    unauthorized 

modification    impossible    to    remain    undetected    takes    time    and    decreases 

productivity. 
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can  be  optionally  set  either  during  software  installation  or  execution  such 
as: 

•  whether  or   not  a  file   should   be  examined   at  all 

•  when   to  examine   the   file    (at   boot  or  execution   time) 

•  how   frequently   to  examine   the   file    (every   time,   every  other,   etc) 

•  how   thoroughly   to  examine   the   file    (the   ratio  of  MAC   to  CRC) 

For  example,  someone  using  a  word  processor  could  opt  for  thorough 
examination  every  15th  execution  instead  of  each  time  it's  used.  A 
programmer  who  infrequently  uses  a  debugger  may  want  to  have  it 
examined  every  time  it  is  used.  The  infrequent  use  means  the  productivity 
impact  is  small,  even  if  a  thorough  examination  is  performed.  Other  non 
sensitive  program  and  data  files  can  be  examined  in  a  more  routine  manner, 
such  as,  using  a  high  speed  algorithm  when  the  computer  is  booted.  This 
approach  could  be  up  to  ten  times  as  fast,  but,  not  offer  the  level  of 
security  of  a  MAC.    (Bosen,   1989) 

On  a  10  MHz  AT,  100  kBytes  can  be  authenticated  in  3.2  seconds   using 
a  hybrid   DES  and  CRC  algorithm.    (Bosen,   1989) 
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VII.      CONCLUSIONS   AND   RECOMMENDATIONS 

Earlier,  I  asked,  "How  do  we  provide  protection  from  viral  attack?". 
I  concluded  the  appropriate  question  should  be,  "How  do  we  prevent  the 
loading  of  infected  software?".  In  retrospect,  the  first  question  allows  us 
to   define  the  foundation   for  the   paradigm   to  answer  the   second. 

Serious  protection  from  viral  attack  should  be  implemented  as  a  three- 
fold  program: 

•  user  training 

•  virus   detection  and   removal 

•  software  authentication 

The   program,   however,  is   best  executed   in  two  phases: 

•  confidence   building 

•  assurance   building 

A.        CONFIDENCE  BUILDING 

These  measures  instill  confidence  in  the  user  and  organization  that 
computer  viruses  are  not  omnipotent  programs  written  by  omniscient 
programmers.  Instead,  they  are  damaging,  but  common,  nuisances  which  can 
be  recognized  and  defeated  with  a  little  effort  and  understanding. 
Confidence  building  measures  would  entail  the  first  two-thirds  of  the  three 
step   program: 


48 


•  user  training 

•  virus   detection  and   removal 

1.  User  Training 

A  solid  foundation  for  further  anti-viral  efforts  must  be  laid  by 
training   computer   users   in   two  areas: 

•  basic   precautions 

•  viral  recognition 

The  basic  precautions  will  provide  good  user  practices  to  reduce 
the  impact  of  viral  damage,  slow  infection  spread,  and,  hopefully,  eliminate 
new  infections.  A  user's  ability  to  recognize  viral  symptoms,  either  by 
suspicious  activity  or  visual  or  audible  cues  is  important.  Recognition, 
before  the  initiation  of  the  damage  sequence,  will  be  damage  and  infection 
limiting.  Use  of  virus  simulations  will  provide  safe  and  realistic  recognition 
patterns. 

2.  Virus   Detection  and   Removal 

Once  the  user  has  developed  sound  prevention  and  identification 
skills,  active  use  of  anti-viral  products  will  help  ensure  a  virus  free 
system.   These  products  should   be  implemented   in  the  following  order: 

•  identification  tools 

•  detection  or  prevention   tools 

The  identification  product  will  ensure  all  existing  infections  are 
identified  and  removed.  Then  the  virus  detection  or  prevention  product  can 
be  installed   to  preclude  new  infections. 
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These   measures   should   be   used  as  follows: 


daily    random    checks   of   on-line    software    as    a    first    line   of    defense 
against  viral  infection 

periodic   deliberate    checks    against    an    off-line    protected    baseline    to 
verify   the   random   verification   means 


B.        ASSURANCE  BUILDING 

While  the  above   measures  will   provide  a  strong   damage  and  infection 
prevention  program,        iitional  m<-  ire  available  which  could   strengthen 

prevention  measures  and  cover  "rinses'  in  their  use.  These  assurance 
building  measures  should  make  use  of  the  inherent  security  of  digitally 
signed  software.  This  means,  when  preparing  software  procurement  contract 
specifications,    organizations    should     require    that    vendors    certify    their 

software    is    virus    free    and    that    it    has    been    digitally    signed    using    a 

2  3 
"approved"   product . 

1.       Software  Authentication 

Several    acknowledged    methods    currently    ex         for    simple    and 
inexpensive  sof'     are  authentic? 'ion: 


Realistically,  most  people  will  not  write  protect  floppy  disks  or  use 
virus  checkers  religiously. 

This  could  be  done  in  conjunction  with  the  National  Institute  of 
Standard  and  Technology  which  is  currently  developing  a  standard  digital 
signature  for  non-repudiation.  Likewise,  vendors  such  as  RSA  provide 
respected  products  and  act  as  agent  for  establishing  and  maintaining  the 
unique  digital  sigi         re  applied  by  each  software  package  sold. 

a  digita  signature  should  be  produced  on  the  vendor's 
develops  at  syste  u  since  it  is  assumed  to  be  uninfected.  This  is  not 
unrealistic  since  infections  of  commercial  programs  to  date  have  been 
traced   to  the  duplication   hardware  and   not  the  development  system. 
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•  use  of  a  public   key   type   signature   product  such  as   Sign   &   Check 

•  use  of  a  one-way   hash   functions   such  as   MD4 

•  use  of  multi-function   products   such  as   VIRUS-SAFE 

The  relative  advantages  and   disadvantages  of  these   methods   include: 


One-way  hash  functions  do  not  require  any  information  to,  be  kept 
secret.    Public   key   systems   require  one   key   be   kept   secret.1 

The  public  key  system  would  not  require  creation  of  substantiating 
documentation.  The  digital  signature  is  either  valid  or  not.  If  its  not, 
the  software  is  not  loaded.  One-way  hash  functions,  however,  require 
that  a  substantial  paper  trail  of  software  valid  hash  codes  be 
maintained.  Conformity  of  the  hash  code  generated  upon  software 
receipt,  with  the  approved  hash  code  maintained  in  the  valid  hash 
codes   documentation,  is   then   required   prior  to  installation. 

The  public  key  system  is  much  simpler  in  application  than  the  one- 
way  hash   function   method. 

Public  key  system  licensing  costs  several  hundred  dollars  per  site. 
The  one-way   hash  function  code  is  in  the  public   domain. 

A  multi-feature  program  could  be  used  in  the  interim  to  validate 
software  while  waiting  for  vendors  to  release  digitally  signed 
software. 


In  the  form  of  the  digital  signature  creation  algorithm.  This  is  kept 
secret  by  the  vendor. 

This  includes  all  versions  and   mini-releases. 

For  this  work,  I  assume  that  NAVELEXSECCEN,  the  Navy's  anti-virus 
command,  will  create  and  maintain  this  paper  trail.  They  will  select  the 
Navy  standard  hash  function,  apply  it  to  all  mission  support  software  in 
Navy's  inventory,  and  release  a  NAVELEXSECCEN  NOTICE  detailing  the 
software  package,  version,  manufacturer,  and  hash  code.  As  new  software 
is  procured  or  updates  received,  NAVELEXSECCEN  will  update  and  reissue 
their  NOTICE.  Of  course,  hashing  for  new  software  could  be  required  by 
the  procurement  contact  to  relieve  NAVELEXSECCEN  of  all  but  the  initial 
effort. 
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C.        THE  BOTTOM   LINE 

A  reliable  anti-virus  product  must  be  robust  enough  to  ensure  its  own 
integrity,  and  sophisticated  enough  to  check  all  executable  files  without 
exception. 

While  evaluating  schemes  for  detecting  and  preventing  viral  spread, 
it  is  important  to  remember  that  viruses  use  the  same  system  capabilities 
available  to  users.  Many  products  and  precautions  may  be  used  to  slow  or 
stop  infection  spread.  Each,  however,  tends  to  reduce  the  computer's 
utility.    As    long    as    we    desire    flexibility,    viru  will    be    able    co    exploit 

legitimate  system  capabilities.  As  viral  programmers  become  more 
experienced  and  develop  new  techniques,  distinguishing  between  legitimate 
and   viral  activity  will  become  an  increasingly  difficult  problem. 

This  requires  more  stringent  protection  and  verification  schemes. 
Their  strength,  however,  should  lie  in  the  verification  process  and  not  in 
protection  or  secrecy  of  the  method.  Since  most,  if  not  all,  of  the  anti-viral 
products  available  today  have  loop  holes  ,  we  must  shift  our  reliance  from 
these  "oducts  to  a  computationally  secure  methodology  for  absolute  virus 
free  environments. 

Since  viral  infection  can  be  traced  to  the  use  of  infected  software", 
the  only  efficient  way  to  preclude  infection  is  to  prohibit  the  use  of 
tainted  programs.   The  only  trustworthy  means  of  prohibition  is  to  require 


Whether  it  be  software  interrupt  monitoring  in  the  prevention 
product,  assumed  clean  baselines  for  the  detection  product,  or  known 
signature  byte  strings  for  the  identification  product,  viruses  can  exploit 
the  weaknesses  of  even  the  most  sophisticated  anti-viral  program. 

While  the  current  generation  of  microcomputer  viruses  live  mostly 
in  executable  images,  this  may   not  necessarily  be  true  in  the  future. 
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that  vendors  cooperate  with   users  in  a   program  of  software  authentication 
using   digital  signatures. 
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VIII.   APPENDICES 


A.        EXAMPLES   OF   DOS   VIRAL    INFECTION   IN   THE    US 


INFECTED  SOFTWARE 


REPORTING  LOCATION 


DATE 


VIRUS 


Unlock  Masterkey 

SARGON  III 

ASYST  RTDEMO02.EXE 

Desktop  Fractal 

Design  System 

Census  Bureau 

1988  Election:  City 

&  County  Data  Bank 

Northern  Computers 


. -nnedy  Space  Center 
Iceland 
Fort  Belvoir 
Various 


Government  Printing 
Office/US  Census  Bureau 


Oct 

89 

Vienna 

Se 

S9 

Cascade  (1704) 

At! 

Jerusalem-B 

Jar 

J 

Jerusalem  (  1813 ) 

Jan 

90 

Jerusalem- B 

Iceland 


Mar  90 


Disk  Killer 


54 


B.        CHRONOLOGY  OF  A  VIRUS   AS   TOLD   BY   IT'S   AUTHOR 

The  author  of  the   Dark   Avenger  virus   has   distributed   it's   source  as 
well  as  a   program,   DOCTOR,   to   remove   it.    DOCTOR   contains   the   following: 


DOCTOR  QUICK:    Virus  Doctor  for  the  Eddie  Virus    Ver  2.01   10-31-89 
(c)  1988-59  Dark  Avenger.   All  rights  reserved.   DOCTOR  /?  for  help 

It  may  be  of  interest  to  you  to  know  that  Eddie  ( aka  "Dark  Avenger")  is  the  most  widespread 
virus  in  Bulgaria  for  the  time  being.  However,  I  have  information  that  Eddie  is  well-known 
in  USA,  W.  Germany  and  USSR  too. 

I  started  writing  the  viru9  in  early  September  1988.  In  those  times  there  were  no  any  viruses 
written  in  Bulgaria,  so  I  decided  to  write  the  first  Bulgarian  virus.  There  were  some 
different  Eddie's  versions: 

VERSION  1.0,  31-OCT-1988 

This  version  established  the  most  important  features  of  the  Eddie  virus.  Staying  resident 
into  high  end  of  memory,  it  was  infecting  .COM  and  .EXE  files,  but  only  when  executing  them. 
INT  13  hadn't  been  handled  in  any  way.  This  version  was  damaging  infected  files  only,  rather 
than  infected  disks.  Also,  there  weren't  any  messages  in  it  (I  still  wasn't  choosed  a  naae 
for  it). 

VERSION  1.1,  16-DEC-1988 

In  December  I've  decided  to  enhance  the  virus.  This  version  could  infect  files  during  their 
opening.  For  that  reason,  a  read  buffer  was  allocated  in  high  end  of  memory,  rather  than 
using  DOS  function  48h  when  needed.  The  disk  was  destroyed  instead  of  the  infected  files. 

VERSION  1.2,  19-DEC-1988 

This  added  a  new  feature  that  causes  (for  example)  coapiled  programs  to  be  infected  at  once 
if  the  virus  is  resident.  Also,  the  "Eddie  lives..."  message  was  added  (can  you  guess  why 
exactly  "Eddie"?) 

VERSION  1.31,  3-JAN-1989 

This  became  the  most  conaon  version  of  Eddie.  A  code  was  added  to  find  the  INT  13  roa-vector 
on  many  popular  XT's  and  AT's.  Also,  other  messages  were  added  so  its  length  would  be  exactly 
1800  bytes.  There  was  a  subsequent,  1.32  version  ( 19-JAN-1989 )  ,  which  added  self -checksum  and 
other  interesting  features  that  was  abandoned  because  it  was  extremely  buggy.  In  early  March 
1989  version  1.31  was  called  into  existence  and  started  to  live  its  own  life  to  all 
engineers'  and  other  suckers'  terror.   And,  the  last 

VERSION  1.4,  17-OCT-1989 

This  was  a  bugfix  for  version  1.31,  and  added  soae  interesting  new  features.  Support  has  been 
added  for  DOS  2.x  and  DOS  4.x.  for  further  information  about  this  (the  most  terrible) 
version,  and  to  learn  how  to  find  out  a  program  author  by  its  code,  or  why  virus-writers  are 
still  not  dead,  contact  Mr.  Vessel  in  Bontchev  (All  Rights  Reserved). 

So,  never  say  die!   Eddie  lives  on  and  on  and  on...   Up  the  irons! 
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C.        KNOWN  VIRUS   INFECTION  AND   DAMAGE  CHARACTERISTICS 

The  information  below,  provided  by  John  McAfee  at  CVIA,  details  the 
major  characteristics  and  number  of  variants,  in  parenthesis,  of  the  known 
IBM    PC   compatible   virus   strains. 


A  Infects  Fixed  Disk  Partition  Table- 
9  Infects  Fixed  Disk  Boot  Sector + 

3  Infects  Floppy  Diskette  Boot 

7  Infects  Overlay  Files + 

6  Infects  EXE  Files + 

5  Infects  COM  files + 

4  Infects  C0MMAND.COM * 

3  Install  Self  in  Memory*  ] 

2  Self -Encrypt  ion *  !  ] 

1  STEALTH  Techniques*  \     \     | 


Virus 


123456789A 

I    I    I    I    I    I    I    I    I    I 

vvvvvvvvvv 


Directly  or  Indirectly: 


Affects  Performance 

♦Corrupts  Programs/Overlays 
♦--Corrupts  File  Linkages 

;  +  ■ Corructs  Data  Files 

I  ;  fCor-    s  Boc   Sector 
!  J  !  *■-         --Fonr-  "s  Disk 


12  3  4  5  6 


V  V  V  V  V  V 


Increase  in 
Infected  Program 
Size 


Azusa 

Lazy 

V-555 

Phantom 

V-299 

Cancer 

1575/1591 

USSR  492 

USSR  1049 

Skism 

Holocaust 

Stone-90 

903 

Dir-Vir 

Hybrid 

IKV528 

Iraqi  Warrior 

Little  Pieces 

Saddam 

Monxla-B 

Plague 

Polish  217 

Sentinel 

Swiss  143 

USSR-311 

Voronezh 

V-961 

USSR-830 

USSR-529 

USSR-516 

USSR-2144 

USSR- 1049 

USSR  (3) 

Tiny-133 

Sverdlov 

Label 

Kukaturbo 


x  x  . 

XXX 
X  X  . 

.   X  . 

.  X  . 
XXX 

.   X  . 

.   X  X 

.  X  X 
X  X  . 
X  X  . 
X  X  . 
X  X  . 
X  X  . 
X  X  . 
X  X  . 

.  X  X 
X  X  . 
X  X  . 

.  X  X 
X  X  . 
XXX 
X  X  . 

.  X  . 
XXX 
X  X  . 
X  X  . 
X  X  . 
X  X  . 
XXX 
X  X  . 

.  .  X 
X  X  . 
XXX 
X  X  . 
X  X  . 


X  .  X 

X  X 

N/A 

X  X  . 

.  . 

720 

XXX 

, 

555 

X  X  . 

.  . 

2253 

X  X  . 

X  . 

299 

X  X  . 

X   . 

1480 

XXX 

varv 

X  X  . 

492 

XXX 

1049 

X  X  . 

1815 

XXX 

X  . 

3784 

X  X  . 

961 

X  X  . 

903 

X  X  . 

X  . 

691 

XXX 

1306 

X  X  . 

528 

XXX 

X   . 

777 

x  x  . 

1374 

XXX 

X  . 

919 

XXX 

535 
Overwrites 

X  X  . 

217 

XXX 

X  . 

4625 

X  X  . 

X  . 

143 

X  X  . 

. 

321 

X  X  . 

X  . 

1600 

X  X  . 

961 

X  X  . 

830 

X  X  . 

529 

X  X  . 

516 

XXX 

X  . 

2144 

X  X   . 

1049 

X  X  . 

575 

X  X   . 

133 

X  X  . 

1962 
Overwrites 
Over-   tes 

56 


Justice 

.XXX. 

XX... 

1242 

Hymn 

X  X  X  X  X 

X  X   .   X   . 

642 

Happv  New  Year 

.   X  X  X  X  X 

XX... 

1865 

Destructor 

X  X  X  X  X 

XX.   .   . 

1150 

Leapfrog  Virus 

.   X  ?  X   .   . 

X  X   .   X   . 

516 

MGTU  Virus  (2) 

.XX. 

X  X   .   X   . 

273 

Nina 

.XXX. 

X  X   .   X   . 

256 

Lozinsky 

.XX. 

X  X   .   X   . 

1023 

BeBe 

.   .XX. 

X  X   .   X   . 

1004 

Best  Wish 

.   X  X  X  J 

c 

X  X   .   X   . 

1024 

Beeper  ( 2 ) 

.   X   .   X   . 

X  X   .   X   . 

4S2 

Parity 

.XX. 

X  X   .   X   . 

441 

Trust  Me 

.   XXX. 

X  X   .   X   . 

417 

USSR-948             .  . 

i  .   .XX) 

£ 

X  X   .   X   . 

94  8 

USSR-711 

i    .     .    x  . 

.   X   .   X   . 

711 

ISSR-707              .  ; 

i.     .   X  X  . 

.   X   .   X   . 

707 

L'SSR-696 

t   .   .   X   . 

.   X   .   X   . 

696 

USSR-600             .  : 

C  .  X  X  ■ 

.   X   .   X  . 

600 

USSR-394 

i      .      X  X   . 

.   X   .   X   . 

394 

USSR-257             .  : 

C   .   X  X   . 

.   X  .   X   . 

257 

USSR-256             .  . 

(.XX. 

.   X   .   X   . 

256 

Christmas  Violator 

.   ?  X   . 

X  X   .   X   .   . 

???? 

Off  Stealth          x 

.  x  x  x  x  : 

<. 

X  X   .   X   . 

1689 

Jeff 

.XX. 

X  X   .   X   .   > 

i          828 

Bloody! 

E  X  •   .   . 

: 

c 

J 

i                  X   ...   X 

n/a 

ZeroHunt            x  : 

C  X   .   X   . 

X  X   .   X   . 

n/a 

Music  Bug  (3) 

.   X   .   .   . 

: 

C  1 

c 

X  ...   X 

n/a 

Dot  Killer 

XXX. 

XX... 

944 

Father  Christmas 

.   .XX. 

XX... 

1881 

3445                 x  : 

C  X   .   X  X 

X  X  X  X  . 

3445 

Mirror  ( 2 ) 

.   X  .   .   X 

XX... 

928 

Polish-2 

XXX. 

X  X   .   X   . 

512 

Polish  217 

.   .XX. 

X  X   .   X   . 

217 

Happy  Day 

.XX. 

XX... 

453 

Monxla 

.   .XX. 

XX... 

939 

USSR                 .  : 

C  .   .   .  X 

XX.   .   . 

575 

Polimer 

.   .XX. 

x  x  .  x  . 

512 

DataLock 

X  .   .   X 

XX... 

920 

Carioca  (2) 

.   X   .   X   . 

XX... 

951 

529 

XXX. 

X  X  .   X  . 

529 

Spyer 

.   X  .   X  X  X 

XX... 

1181 

Taiwan4 

X  X  X  X  X 

X  X  .   X  . 

2576 

Keypress  (3) 

.   X  X  X  X  . 

X  X   .   X   . 

1232 

Casper              .  : 

(.XX. 

X  X  X  X  . 

1200 

1605 

.   X  X  X  X 

X  X  X  X   . 

1605 

Violator  (6) 

.XX. 

X  X  .   X  . 

1055 

Blood-2 

.   .   .   X  . 

X  X  .   X   . 

427 

Wisconsin           .  : 

t     .   XX. 

X  X  .   X  . 

825 

Chnstmas-J 

.   X  X  X  X 

XX... 

600 

Austria  ( 3 ) 

.xxx 



Overwrites 

Leprosy-B 

.   .XXX 

Overwrites 

Whale  (3)            x  : 

C  X  X  X  X  X 

X  X  X  X   . 

9216 

Invader  (4) 

k  x  .  x  x  x  : 

i   1 

c 

X  X  X  X  X 

4096 

Scott's  Valley 

I  X  .   X  X  X 

X  X  X  X  . 

2133 

Anarkia  (2) 

.   X  .   X  X  X 

X  X   .   X   . 

1813 

Black  Monday  (2) 

.  X  X  X  X  X 

X  X  X  X   . 

1055 

Nomenclature  (4) 

.   X  X  X  X  X 

X  X   .   X   . 

1024 

Anthrax  -  Boot  (2) 

.  X  .   .   .   . 

) 

c     x  x  .  x  . 

n/a 

Anthrax  -  File  (4) 

.  X  X  X  X  . 

X  X  .   X   . 

1206 

651 

.  X  .  X  .   . 

X  X  .   X  . 

651 

Paris 

.   .  X  X  X  X 

X  X  X  X  . 

4909 

Leprosy  ( 5 ) 

.   X  X  X  X  X 



Overwrites 

Mardi  Bros.  (3) 

.   X  .   .   .   .XX 

X  ...   X 

n/a 

1253  -  Boot 

.   X   .   .   . 

x  x  : 

C        X  X  X  X  . 

n/a 

1253  -  COM 

.XXX. 

.        X  X  X  X  . 

1253 

AirCop  (3) 

.   X   .   .   . 

X   . 

X   ...   X 

n/a 

400  (5) 

.   X  .   X  . 

X  X  .   X   . 

vary 

PI  (6) 

K  X  .  X  . 

X  X  X  X   . 

varv 

57 


Ontario 

x  x  x  x  x  . 

XX,, 

£ 

varv 

1226  (3) 

X  X  X  X  X  X 

X  X   .   X 

1226 

V2100  (2) 

.   X  .  X  x  . 

X  X  X  X 

2100 

Plastique  (9) 

.   X  X  X  X  X 

X  X   .  X 

3012 

Wo   tan  ( 2 ) 

.   X  X  X  X   . 

XX.. 

2064 

Dooiti  I 

.   X   .   X  X  . 

X  X  X  X 

2504 

Flip  (4) 

X  X  X  X  X  X 

X  X  X  X 

2343 

Fellowship  (3) 

.   X  .   .   X   . 

X  X  X  X 

1022 

Flash 

.   X  X  X  X  . 

X  X  X  X 

688 

1008 

X  X  X  X  .   . 

X  X  X  X 

1008 

Stoned-II 

.  x  .  .  .  .  : 

£ 

: 

£     x  .  x  .  x 

n/a 

Taiwan3 

.   X  X  X  X  X 

X  X  X  X 

2905 

Armagedon  ( 3 ) 

.XXX.   . 

XX.. 

1079 

13S1 

.   .   .   .   X  X 

X  X   . 

1381 

Tinv  ( 13 ) 

.   .XX.. 

X  X   . 

163 

Subliminal  (3) 

.XXX.   . 

X  X   . 

1496 

Sorry 

.XXX.   . 

X  X   . 

731 

RedX  (2) 

.   .XX.. 

X  X   . 

796 

1024  (2) 

.XXX.   . 

X  X  . 

1024 

Joshi  (4             J 

!   .   X   .   .   .   .   X  X  3 

c     x  .  .  x  x 

n/a 

Microbes 

.   X  .   .   .   .XX 

X   .   .XX 

.          n/a 

Print  Screen  (2) 

.   X   .   .   .   .XX 

X  .   .XX 

n/a 

Form  ( 2 ) 

.   X   .   .   .   .XX 

X   .   .   X  X 

n/a 

July  13th 

X   .   .   .   X   .   . 

X  X  X  X   . 

1201 

5120  (3) 

.   .   X  X  X  X 

X  X  X  X 

5120 

Victor  (2) 

.   X  X  X  X  X 

.XXX 

2458 

JoJo  ( 3 ) 

.   X  .   X  .   . 

XX.. 

1701 

W-13  (4) 

.   .   .   X  .   . 

X  X  . 

532 

Slow  (5) 

X  X  .   X  X  X 

XXX 

1721 

Frere  Jacques 

.   X   .   X  X  X 

X  X   . 

1811 

Liberty  (2) 

.   X  X  X  X  X 

X  X  . 

2862 

Fish-6  (2)          ) 

I     X  X  X  X  X  X 

XXX 

3584 

Shake 

.   X  .   X  .   . 

X  X   . 

476 

Murphy 

.  X  X  X  X  X 

X  X  . 

1277 

V800  (3)             j 

£  X  X   .   X   .   . 

XXX 

none 

Kennedy  ( 3 )          . 

.   X   .   X  .   . 

X  X  . 

308 

8  Tunes/1971  (2) 

.   X  .   XXX 

X  X  . 

1971 

Yankee- 2 

.   .   .XX. 

X  X  . 

1961 

June  16th 

.   .XX.. 

XXX 

x         1726 

XA1 

X  .   .  X  .   . 

XXX 

x         1539 

1392 

.   X  X  X  X  . 

XXX 

1392 

1210 

.   X   .   X  .   . 

XXX 

1210 

1720  (3) 

.   X  .   XXX 

XXX 

x         1720 

Saturday  14th  (3) 

.   X  .  X  X  X 

XXX 

X 

K<  ea  (4) 

: 

{.    : 

t 

X   .   . 

3 

c  .          n/a 

V   nn  <  5  ) 

.   .   .   .  X  . 

XXX 

1074 

I   /ir 

.   .   .   .   X  . 

XXX 

: 

c 

3880 

S-  xno  (  3 ) 

.   X  .  X  .   . 

XXX 

2000 

V^JOO  (3) 

.  X  X  X  X  X 

XXX 

2000 

1359 

.  X  X  X  X  . 

XXX 

1554 

512  (5)             : 

C  .  X  X  X  .   . 

XXX 

none 

EDV  (2)             i 

t  .   X  ....   3 

£  3 

C     3 

C       X  .   . 

2 

c 

n/a 

Joker 

.XXX.   . 

X  X  . 

Icelandic-3 

.  X  .   .  X  . 

X  X  . 

353 

Virus-101 

x  x  x  x  x  x  : 

£ 

.   X   . 

2560 

1260  (3) 

X  .   .  X  .   . 

.   X   . 

1260 

Perfuse  (2) 

.   .   .   X  .   . 

.  X  . 

765 

Taiwan  (3) 

.   .   .  X  .   . 

.   X  . 

708 

Chaos 

.  x  .  .  .  .  : 

(.   . 

£ 

x  .  .  : 

t  . 

£  ; 

£          n/a 

Virus- 90 

.  x  .  x  .  . 

.   X  . 

857 

Oropax  ( 5 ) 

.  x  .  x  .  . 

X  X  . 

2773 

4096  (4)             J 

C  .  X  X  X  X  X 

x  x  x  x 

4096 

Devil's  Dance  (2) 

.   X  .   X  .   . 

X  X  X  X 

941 

Amstrad  (5) 

.   .   .  X  .   . 

.   X  .   . 

847 

Payday  ( 2 ) 

.   X  .   XXX 

.   X  . 

1808 

Da  taeniae  II-B 

X   .   X  X  X  . 

.   X  . 

3 

c         1917 

Sylvia/Holland 

.   .   .   X  .   . 

.   X  . 

1332 

Do-Nothing 

.  X  .  X  ■   . 

.   X  . 

608 
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Sunday  (4) 

.  .  x  . 

XXX.   . 

X  X      . 

1636 

Lisbon  (2) 

> 

X   .   .   .   , 

.      X      . 

648 

Typo/Fumble 

■   .   X   . 

X   .   .   .   . 

X  X   . 

667 

Dbase 

.   X   . 

X   .   .   .   . 

xx.; 

i    . 

1S64 

Ghost  Boot 

.   .   X   . 

.   .   .   X  X 

X  .  . 

.   X 

n/a 

Chost  COM 

X   .   .   .   . 

.  X  ■ 

X 

2351 

New  Jerusalem 

.   .   X   . 

X  XX.   . 

X  X 

1308 

Alabama  (3) 

.   X   . 

X   .   .   . 

X  X  X 

1560 

Yank  Doodle  (6) 

.   X   . 

XX.   .   . 

X  X   . 

2885 

2930 

.   X   . 

XX.   .   . 

.   X   . 

2930 

Ashar 

.   X   . 

.   .   .   X   . 

X 

n/a 

AIDS  (4) 

.  .  . 

X   .   .   .   . 

Overwrites 

Disk  Killer  (4 ) 

.   X   . 

.   .   .   X  X 

XX.. 

i     X  . 

t          n/a 

1536/Zero  Bug 

.   X   . 

X   .   .   .   . 

X  X   . 

1536 

MIX1 

X   . 

.   X   .   .   . 

X  X 

161S 

Dark  Avenger  ( 4 ) 

.   X  X 

XXX.   . 

XXX 

1300 

3551/Svslock 

X   .   . 

XX.   .   . 

.  x  .  ; 

<  . 

3551 

VACSINA  (5) 

.  X  . 

XXX.   . 

X  X   . 

1206 

Ohio 

.   X   . 

.   .   .   X   . 

X 

n/a 

Tvpo  Boot 

.   X   . 

.   .   .   X  X 

X   .   . 

X 

n/a 

Swap  Boot 

.   X   . 

.   .   .   X   . 

X 

n/a 

Datacrime-2  (2) 

X   .   . 

XX... 

.   X   . 

:         1514 

Icelandic  II 

.   X   . 

.   X   .   .   . 

X  X   . 

661 

Pentagon 

.   .   .   X   . 

.  .  . 

n/a 

Traceback  ( 3 ) 

.   X   . 

XX... 

.   X   . 

3066 

Datacrime-B 

X   .   . 

X   .   .   .   . 

.   X   . 

.  } 

c         1168 

Icelandic  (2) 

.   X   . 

.   X   .   .   . 

x  x  . 

642 

Saratoga 

.   X   . 

.   X   .   .   . 

X  X   . 

632 

405 

.  .  . 

X  .   .   .   . 

Overwrites 

1704  Format 

X  X   . 

X   .   .   .   . 

X  X   . 

.  > 

[          1704 

Fu  Manchu  ( 4 ) 

.   X  . 

XXX.. 

X  X  . 

2086 

Datacrime  (2) 

X   .   . 

X   .   .   .   . 

.   X   . 

.  > 

[         1230 

1701/Cascade 

X  X   . 

X  .   .   .   . 

X  X   . 

1701 

CASCADE-B  (9) 

X  X  . 

X  .   .   .   . 

X  X  . 

1704 

Stoned  (5) 

.   X  . 

.  .  .  x  .  : 

i                   X   .   X 

X 

n/a 

1704/CASCADE 

X  X   . 

X  .   .   .   . 

X  X   . 

1704 

Ping  Pong-B  (2) 

.   X  . 

.   .   .   X  X 

X  .   . 

X 

n/a 

Den  Zuk  ( 3  ) 

.   X   . 

.   .   .   X   . 

X  .   . 

X  . 

n/a 

Ping  Pong  ( 5  ) 

.   X   . 

.   .   .   X   . 

X   .   . 

X 

n/a 

Vienna-B 

X 

.   X   .   . 

648 

Lehigh 

.   X  X 



.   X  . 

.  ; 

c      Overwrites 

Vienna/648  (23) 

X  .   .   .   . 

.   X  .   . 

648 

Jerusalem-B 

X   . 

XXX.. 

X  X  . 

1808 

Alameda  (2) 

.   X  . 

.   .   .   X   . 

. 

X  . 

n/a 

Friday  13th  COM 

.  .  . 

X  .   .   .   . 

.   X   . 

512 

Jerusalem  ( 17 ) 

.   X  . 

XXX.. 

XX.. 

1808 

SURIV03 

.   X  . 

XXX.. 

X  X  . 

SUBIV02 

.   X   . 

.   X   .   .   . 

XX.. 

1488 

SURIV01 

.  X  . 

X   .   .   .   . 

X  X  . 

897 

Brain  (3) 

.   X  . 

.   .   .  X   . 

.  .  .  . 

X  . 

n/a 

Total  Known  Viruses  -  481 

LEGEND: 

Size  Increase: 

N/A        -  Virus  does  not  attach  to  files. 

None       -  Virus  does  not  change  size  (attaches  to  file  end) 
Overwrites  -  Virus  overwrites  beginning  of  file,  no  size  change 
All  Others  -  Length  in  bytes  a  file  will  increase  when  infected. 

Characteristics: 
x  -  Yes 
.  -  No 
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D.        ANTI-VIRAL   PRODUCT   MINIMUM   CAPABILITIES    LIST 

The  minimum  capabilities  in  the  sections  below  are  recommended  by 
John  McAfee  at  CVIA.  They  can  be  used  to  provide  a  rough  cut  on 
prospective  anti-viral  products.  Acceptable  products  should  then  be 
evaluated   using   the   testing   criteria  in  Appendix   E. 

1.       Infection   Prevention   Products 


Differentiate  between  activities  initi  i  by  the  user  and  activities  carried  out 
autonomously  by  urograms.  Users  may  dele  sr  update  program  files  or  operating  system 
segments.  An  ^plication  program,  on  .e  other  hand,  should  not,  under  normal 
circumstances,  modify  another  application  program,  an  operating  system  program,  or  the 
system's  boot  sector.  This  is  indicative  of  viral  activity; 

Provide  few  false  positives,  or  false  alarms.  Users  become  habituated  to  frequent  false 
alarms  and  tend  to  overlook  a  valid  virus  warning  when  it  does  occur; 

Run  with  other  memory  resident  programs.  Infection  prevention  programs  are  all  memory 
resident  and  they  modify  a  large  number  of  software  interrupts.  This  gives  such 
programs  a  propensity  for  crashing  or  hanging  the  system  when  running  concurrently  with 
other  memory  resident  programs; 

Protect  against  modifications  to  all  executable  data,  including:  the  system's  boot 
sector,  device  drivers,  operating  system  modules,  including  hidden  file  programs,  and 
all  application  programs; 

Provide  an  easily  accessible  enable/disable  switch.  Many  instances  will  occur  where  the 
checking  process  will  need  to  be  temporarily  suspended; 

Provide  the  ability  to  selectively  protect  or  ignore  specific  programs  or  specific 
areas  of  the  system.  This  will  reduce  the  number  of  false  alarms  when  running  programs 
which  violate  the  "rules"  imposed  by  the  product; 

Provide  the  ability  to  freeze  virus  activity  when  it  is  detected,  and  prp'  ^nt  the 
illegal  access  from  continuing.  This  is  mandatory  to  prevent  the  virus  from  ecting 
the  system; 

Run  without  noticeably  degrading  system  performance.  Memory  resident  programs  have  a 
tendency  to  increase  system  overhead  and  thus  slow  down  the  system.  A  well  designed 
product  should  cause  no  more  than  a  5%  degradation  in  system  performance; 

Monitor  and  protect  all  attached  read/write  devices.  All  attached  devices  that  can  be 
written  to  are  potential  virus  targets.  The  prevention  product  should  protect  all  such 
devices;  and, 

Selectively  prevent  interrupt  level  I/O  and  non-standard  calls  for  I/O  service 
(interrupt  level  requests).  Since  doing  so  increases  the  false  alarm  rate,  the  user 
should  have  the  choice  of  allowing  or  disallowing  such  calls. 


2.       Infection  Detection   Products 


Detect  characteristic  viral  modifications  to  execut  :e  data,  including:  the  system's 
boot  sector,  system  device  drivers,  operating  systeta  modules,  including  hidden  file 
programs,  and  all  application  programs; 
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Allow  the  user  to  selectively  exclude  specific  programs  or  areas  of  storage  from 
checking.  This  will  allow  programs  or  directories  that,  undergo  frequent  change  to  avoid 
causing  error  messages; 

Perform  global  check  functions  tn  a  timely  fashion.  If  the  check  function  is  executed 
at  boot  time,  for  example,  it  should  add  no  more  t'lan  10  seconds  to  the  boot  sequence 
for  each  50  programs  on  the  disk  that  must  be  checked; 

Provide  automatic  checking.  The  check  function  should  execute  at  least  each  time  the 
system  is  powered  on  or  re-booted.  Some  systems  provide  a  clock  function  so  that  the 
system  can  be  checked  automatically  at  user  specified  time  intervals; 

Stop  the  system,  provide  a  visual  and  audible  warning,  and  wait  for  user  directions  if 
a  potential  virus  is  detected;  and, 

Display  the  names  of  all  programs  or  system  areas  that  have  become  infected. 

3.       Infection   Identification   Products 

Identify  and  remove  multiple  virus  strains; 

Provide  information  to  allow  the  user  to  determine  the  diagnosis  accuracy.  Modified 
viruses  can  sometimes  only  be  detected  by  cross  referencing  many  different 
characteristics.  The  product  should  provide  the  degree  of  certainty,  or  other 
information  that  can  be  used  to  determine  a  course  of  action,  for  any  questionable 
virus ; 

Identify  and  report  infected  system  areas  and  the  extent  of  infection; 

Inform  the  user  of  the  anticipated  degree  of  success  for  removal.  Depending  on  the 
length  of  time  since  infection,  removal  may  or  may  not  be  possible.  The  product  should 
inform  the  user  of  possible  options  including  automatic  removal  or  erasure  of  the 
affected  system  element; 

Scan  and  remove  infection  from  all  attached  devices  including  floppies,  fixed  and 
removable  hard  disks,  and  tape  devices; 

Automatically  scan  all  subdirectories; 

Flag  all  system  areas  where  removal  was  incomplete.  These  areas  must  be  manuallv  dealt 
with  after  the  program  finishes;  and, 

Prevent  self  infection  during  the  identification  and  removal  process.  An  infected 
identification  product  will  run  the  risk  of  infecting  every  system  on  which  it  is  used. 
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E.        ANTI-VIRAL   PRODUCT   EVALUA'I     )N   PROCEDURES 

The  test  procedures  in  the  sections  below  are  recommended  by  John 
McAfee  at  CVIA.  While  not  scientifically  rigid,  they  will  provide  additional 
performance  information  not  otherwise  obtainable.  Any  product  that 
performs   well   in   testing   will   provide   some   degree  of   real   protection. 

1.       Infection   Prevention   Products 

•  Install  the  antiviral  product; 

•  Test  the  product's  ability  to  protec  Jeneral  executable  programs  from  being  modified. 
Create  a  temporary  subdirectory  and  r  your  word  processor  into  it.  Create  two  output 
text  files  named  TEST,  one  with  a  .  extension  and  the  other  with  a  .COM  extension. 
Then  attempt  to  update  the  file  usir.^  ne  word  processor.  The  antiviral  program  should 
flag  both  the  creation  and  the  update  as  a  potential  infection.  Repeat  these  steps  for 
the  system  files  (IBMBI0.COM,  IBMD0S.COM,  and  C0MMAND.COM)  as  well  as  all  device 
drivers.  Repeat  each  of  these  steps  using  a  floppy  diskette  as  the  output  device, 
instead  of  the  hard  disk  subdirectory.  The  same  results  should  occur. 

•  Test  the  product's  ability  to  prevent  interrupt  level  I/O.  First  copy  the  FORMAT 
routine  to  a  file  named  TEST.COM.  Run  TEST  and  format  a  floppy  diskette  in  the  A  or  B 
drive.  The  antiviral  program  should  prevent  the  format  and  flag  the  attempt. 

•  Test  the  use  of  operating  system  commands.  User  commands  are  frequently,  and 
erroneously,  flagged  bv  antiviral  products  when  they  instigate  operations  that  mimic 
virus  activities.  Usir<?  COPY,  DELETE  and  RENAME  commands,  copy  an  executable  program 
into  a  different  directory,  rename  it  to  another  EXE  or  COM  file  name,  and  then  delete 
it.  None  of  the  three  operations  should  be  flagged  by  the  antiviral  program. 

•  Verify  that  the  above  functions  would  be  stopped  if  performed  by  a  program,  rather  than 
by  the  user.  Using  any  application  utility  program  that  has  cony,  rename  and  delete 
functions  ,  repeat  the  above  series  of  steps.  The  antiviral  pr-  n  should  prevent  and 
flag  all  three  attempts  as  potential  viral  activities. 

•  Test  self  modification.  Many  programs  modify  their  own  executable  modules  a  some 
point.  The  antiviral  program  should  not  flag  or  prevent  this.  To  test  this,  cot  your 
word  processor  executable  module  to  a  backup  file.  Then  run  the  word  processor,  create 
a  dummy  document,  and  then  save  it  to  the  name  of  the  executable  word  processor  module. 
The  antiviral  program  should  allow  the  modification.  After  this  test,  copy  the  saved 
version  of  the  program  back  to  its  original  name. 

•  Test  for  detection  of  boot  sector  modification.  Using  any  utility  that  allows  reading 
and  writing  the  boot  sector,  read  the  boot  sector  and  write  down  the  contents  of  the 
first  byte.  Change  the  first  byte  to  00  and  a ;  :  empt  to  write  the  sector  back  to  disk. 
The  product  should  prevent  the  attempt.  If  »  product  fails,  replace  the  original 
contents  of  the  first  byte  and  re-write  the  boot  sector.  The  re-write  should  be 
performed  prior  to  shutting  down  or  re-booting  the  system. 

•  Teat  for  memory  residence.  Many  viruses  modify  the  original  structure  of  programs  so 
that  they  remain  memory  resident  after  they  terminate.  The  antiviral  product  should 
detect  any  attempt  to  remain  resident.  To  test  this  feature,  merely  take  any  normally 
memory  resident  program,  such  as  SIDEKICK  or  CACHE,  and  rename  it  to  the  file  TEST.C0M 
(or  .EXE,  depending  on  the  program).  Run  TEST.  The  product  should  catch  the  program  and 
display  a  warning  message. 
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2.       Infection  Detection   Products 


Test  for  detection  of  boot  sector  replacement.  Using  a  disk  utility,  create  a  safe 
unique  boot  sector  by  blanking  out  the  "Boot  Failure"  message.  Then  install  the 
detection  product  you  wish  to  test.  Next,  replace  the  entire  boot  sector  using  the  SYS 
command.  Then  execute  the  check  function  of  the  product  you  are  testing.  The  product 
should  warn  that  the  new  boot  sector  is  a  replacement. 

Test  for  detection  of  boot  modification.  Next,  re- install  the  detection  product.  Then 
modify  the  boot  sector  randomly  using  the  disk  utility.  Run  the  check  routine.  The 
product  should  warn  that  the  boot  sector  has  been  modified.  (When  finished  with  this 
step,  perform  the  SYS  command  again,  or  use  the  disk  utility  to  return  the  boot  sector 
to  its  original  state). 

Test  for  detection  of  program  deletion.  Copy  a  number  of  COM  and  EXE  files  to  a 
temporary  directory  and  then  delete  the  originals.  Run  the  detection  check  function. 
The  product  should  identify  each  of  the  missing  programs. 

Test  for  detection  of  program  modification.  Copy  the  programs  back  from  the  temporar\ 
directory  to  their  original  directories.  Using  your  disk  utility,  modify  the  first  byte 
of  each  of  the  COM  programs.  Modify  the  entire  first  500  bytes  of  the  EXE  programs. 
Run  the  check  program.  Each  modification  should  be  detected.  At  this  point  you  should 
replace  each  of  the  modified  programs  from  the  original  programs  stored  in  the 
temporary  directory. 

Test  for  detection  of  program  replacement.  Replace  an  application  program  with  the 
original  from  the  distribution  diskette.  Then  modify  the  program  as  above.  The  check 
function  should  still  catch  the  modification. 

Test  for  detection  of  system  modification.  Using  a  disk  utility,  copy  IBMBI0.COM, 
IBMD0S.COM,  and  C0MMAND.COM  to  backup  files.  Randomly  modify  each  of  the  original 
files,  using  the  disk  utility,  by  changing  only  one  byte  in  each.  Run  the  check  routine 
to  determine  that  the  modifications  have  been  detected.  Perform  this  step  multiple 
times  with  different  modifications. 

3.       Infection  Identification  Products 


The  first  steps  are  to  isolate  the  infected  system  from  all  others,  and  to  acquire 
clean,  original  copies  of  the  infected  programs.  Make  working  copies  of  these 
uninfected  programs  onto  separate  floppy  diskettes,  one  sample  program  per  diskette. 

Insert  each  floppy  in  turn  into  the  infected  system  and  run  each  sample  program.  This, 
in  most  cases,  will  cause  the  diskette,  or  the  program,  to  become  infected. 

Using  a  disk  utility,  do  a  binary  compare  of  the  infected  diskette  to  the  backup  copy. 
If  an  infection  has  occurred,  the  diskettes  will  differ.  Separate  all  working  copy 
diskettes  that  have  been  modified  by  the  virus  and  label  them  as  infected. 

Now  run  the  identification  program  against  each  of  the  infected  floppies.  Do  this  on 
a  clean,  uninfected  system.  The  program  should  identify  the  infection  on  each  diskette. 
Next  cause  the  program  to  attempt  removal.  Run  each  floppy  in  turn  through  the  removal 
cycle.   The  program  should  remove  all  of  the  infections. 

To  test  that  the  removal  worked,  take  the  infected  (and  now  hopefully  disinfected) 
diskettes  and  again  do  a  binary  compare  against  the  original  backup  diskettes.  There 
should  be  no  discrepancy. 

If  the  program  has  passed  the  above  tests,  it  is  clearly  able  to  identify  and,  at  least 
in  test  disks,  remove  the  infection.  At  this  point  you  should  test  its  operation  on  the 
infected  system.  To  do  this,  first  make  a  backup  copy  of  the  product.  Then  load  the 
identification  program  into  the  infected  system  and  begin  the  identification  and 
disinfection  process. 
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On  completion  of  the  operation,  perform  a  disk  compare  of  the  working  disk  against 
original  product  disk.  There  should  be  no  differences. 


th- 
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F.        ANTI-VIRAL   SOFTWARE 

The   following  anti-viral   products  are  available  commercially 
1.       Infection   Prevention   Systems 


Product 


Vendor 


Phone 


ACE  System 
Data  Physician 


Disk  Defender 
Flu-shot+ 


FShield 


F-PROT 


Norton  Antivirus 


VirALARM  2000 


Virus  Implant  Protector 


Security  Dynamics 

Digital  Dispatch 

1580  Rice  Creek  Road 

Minneapolis,  MN    55432 

Director  Technologies 

Software  Concepts  Design 

594  Third  Avenue 

New  York,  NT    10016 

McAfee  Associates 

4423  Cheeney  Street 

Santa  Clara,  CA    95054 

Box  7180 

IS-127  Reykjavik 

Iceland 

10201  Torre  Avenue 

Cupertino,  CA    95014 

Lasertrieve 

395  Main  Street 

Metuchen,  NJ    08840 

Leemah  Data con  Security 

3948  Trust  Way 

Hayward,  CA   94545 


(617)  547-7820 
(612)  571-7400 


(312)  491-2334 
(212)  889  6438 


(  108)  988-3832 


(800)  343-4714 
(201)  906-1901 

(415)  786-0790 


2.       Infection   Detection  Systems 


Product 


Vendor 


Phone 


Sentry 
Tracer 
Vaccinate 


Virus-Pro 
Virus  Safe 


(408)  988  3832 
(408)  988-3832 
(800)  922-3001 


McAfee  Associates 

McAfee  Associates 

Sophco 

P.O.  Box  74  30 

Boulder,  CO   80306 

International  Security      (212)  288-3101 

Technologies 
Enigma  Logic  Inc.  (415)  827-5707 

2151  Salvio  Street,  #301 
Concord,  CA    94565    USA 


3.       Infection  Identification  Systems 


Product 


Vendor 


Phone 


Detect 
Scan  Virus 

Viruscan 
V-Finder 


McAfee  Associates 

IBM 

McAfee  Associates 

WallyWare 


(408)  988-3832 

(800)  426-2468 

(408)  988-3832 

(408)  275-6358 
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G.   MD4  LISTING 


/* 

*«  md4.c  --  Implementation  of  tlD4  Message  Digest  Algorithm  ** 

«*  Updated:  2/16/90  by  Ronald  L.  Rivest  ** 

«*  (C)   1990  RSA  Data  Security,   Inc. 

I  *  »  *  »  t  .  I  .  t  .  .  *  l  »  ►  *  *  *.  »  4  t  *  *  c  «  *  K  t:  *  *  *  •:  *  *  *  »  •.  e  *  t  *  *  *  *  ft  k  *  *  *  t  *  *  t    *  *-  »  *  *  f  t  t  »  »  *  *  *  »  t  »  *  t 

*/ 
/* 

**  To  use  MD4 : 

**  --  Include  md4 . h  in  your  program 

**  --  Declare  MDstruct  MD  to  hold  the  state  of  the  digest  computation. 

**  --  Initialize  MD  using  MDbegin(tMD) 

**  --  For  each  full  block  (64  bytes)  X  you  wish  to  proce~~   call 

**  MDupdate(&MD,X,512) 

**  (512  is  the  number  of  bits  in  a  full  block.) 

**  --  For  the  last  block  (less  than  64  bytes)  you  wish  1      cess, 

**  MDupdatet  WID.X.n) 

**  where  n  is  the  number  of  bits  in  the  partial  block    partial 

**  block  terminates  the  computation,  so  every  MD  computation  should 

**  terminate  by  processing  a  partial  block,  even  if  it  has  n  =  0. 

**  --  Message  digest  is  available  in  MD.buffer[0]  ...  MD. buf ferf 3] . 

**  (Least-significant  byte  of  each  word  should  be  output  first.  ) 

**  --  You  can  print  out  the  digest  using  MDprint(&MD) 


•/ 

/*  Implementation  notes: 

**  This  implementation  assumes  that  ints  are  32-bit  quantities. 

**  If  the  machine  stores  the  least-significant  byte  of  an  int  in  the 

**  least -addressed  byte  (VAX  and  8086),  then  LOWBYTEFIRST  should  be 

**  set  to  TRUE.   Otherwise  (eg.,  SUNS),  LOWBYTEFIRST  should  be  set  to 

**  FALSE.   Note  that  on  machines  with  LOWBYTEFIRST  FALSE  the  routine 

**  MDupdate  has  a  side-effect  on  its  input  array  (the  order  of  bytes 

**  in  each  word  are  reversed).  If  undesired,  a  MDreverse(X)  call  can 

**  reverse  the  bytes  of  X  back  into  order  after  each  call  to  MDupdate. 

*/ 

tdefine  TRUE  1 
♦define  FALSE  0 
♦define  LOWBYTEFIRST  TRUE 

/*  Compile-time  includes 
«/ 

♦include  <stdio.h> 
♦include  "ad4.h" 

/*  Compile-time  declarations  of  MD4  '"magic  constants'". 
*/ 

♦define  10  0x67452301       /*  Initial  values  for  MD  buffer  */ 

♦define  II   0xefcdabS9 

♦define  12   0x98badcfe 

♦define  13   0x10325476 

♦define  C2   013240474631      /*  round  2  constant  =  sqrt(2)  in  octal  */ 

♦define  C3   015666365641      /*  round  3  constant  -    sqrt(3)  in  octal  */ 

/*  C2  and  C3  are  froa  Knuth,  The  Art  of  Programming,  Volume  2 

**  (Seminumerical  Algorithms),  Second  Edition  (1981),  Addison-Wesley. 

**  Table  2,  page  660. 

*/ 

♦define  fsl   3  /*  round  1  shift  amounts  */ 

♦define  fs2   7 

♦define  fs3  11 
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♦define  fs4  19 

♦define  gsl  3  /*  round  2  shift  amounts  */ 

♦define  gs2  5 

♦define  gs3  9 

♦define  gs4  13 

♦define  hsl  3  /*  round  3  shift  amounts  */ 

♦define  hs2  9 

♦define  hs3  11 

♦define  hs4  15 


/*  Compile-time  macro  declarations  for  MD4  . 

**  Note:  The  ''rot1'  operator  uses  the  variable  ''trap''. 

"  It  assumes  tmp  is  declared  as  unsigned  int ,  so  that  the  >> 

**  operator  will  shift  in  zeros  rather  than  extending  the  sign  bit. 

*/ 

♦define  f(X,Y,Z)  ( ( X&Y )  I  (CX)&Z>> 

♦  define  g(X,Y,Z)  ((X&Y)  \     (  X&Z  )  1  ( Y«tZ  )  ) 
♦define  h(X,Y,Z)             (X"Y"Z) 

♦define  rot(X.S)  ( tmp=X , ( trap< < S )  |  ( tmp> x 32-S  )  ) ) 

♦  define  f  f  (  A  ,  B  ,  C  ,  D  ,  l  ,  s  )       A  =  rot((A  t-  f(B,C,D)  t  X[i]),s) 
♦define  gg( A , B , C , D , i , s  )       A  =  rot((A  ♦  g(B,C,D)  *    X[i]  t  C2),s) 
♦define  hh(  A  ,  B  ,  C  ,  D  ,  i  ,  s  )       A  =  rot((A  <■  h(B,C,D)  f  X[i]  +  C3),s) 

/*  MDprmUMDpl 

**  Print  message  digest  buffer  MDp  as  32  hexadecimal  digits. 

**  Order  is  low-order  byte  of  bufferfO]  to  high-order  byte  of  buffer[3] 

**  Each  byte  is  printed  with  high-order  hexadecimal  digit  first. 

**  This  is  a  user-callable  routine. 

*/ 

void 

MDpnnt  (MDp) 

MDptr  MDp; 

{  int  i  ,  j  ; 

for  ( i=0; i<4 ; i++ ) 
for  fj=0;j<32;j=j+8) 

pnntf  ("%02x"  ,  <MDp->buffer[i]  >>  j  )  4  OxFF); 
} 

/*  MDbegin(MDp) 

**  Initialize  message  digest  buffer  MDp. 

**  This  is  a  user-callable  routine. 

*/ 

void 

MDbegin(MDp) 

MDptr  MDp; 

{  int  i ; 

MDp->buffer[0]  =  10; 

MDp- > bufferf 1]  =  II; 

MDp->buffer[2]  =  12; 

MDp- > buffer! 3]  -    13; 

for  (i=0;i<8;i++)  MDp- > count [ i ]  =  0; 

MDp- > done  =  0; 
} 

/*  MDreverse(X) 

**  Reverse  the  byte-ordering  of  every  int  in  X. 

**  Assumes  X  is  an  array  of  16  ints. 

**  The  macro  revx  reverses  the  byte-ordering  of  the  next  word  of  X. 

*/ 

♦define  revx  {  t  =  ( *X  <<  16)  ,'  ( *X  >>  16);  \ 

*X++  =  <<t  k   OxFFOOFFOO)  >>  8)  |  <(t  &  OxOOFFOOFF)  <<  S);  } 
MDreverse( X ) 
unsigned  long  int  *X; 
{  register  unsigned  long  int  t; 

revx;  revx;  revx;  revx;  revx;  revx;  revx;  revx; 

revx;  revx;  revx;  revx;  revx;  revx;  revx;  revx; 
} 
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/* 

*  r 


MDblock(MDp.X) 

Update  message  digest  buffer  MDp-> buffer  using 

Assumes  all  16  words  of  X  are  full  of  data. 

Does  not  update  MDp->count . 

This  routine  is  not  user-callable. 


16-word  data  block  X. 


=  / 


stat  ic  void 
MDblock(MDp.X) 
IDptr  IDp; 
unsigned  long  tnt  ►> 

{ 

register  unsigned 
#if  LOWBYTEFIRST  == 

MDreversefX  )  ; 
♦  end  1  f 


long  int 
FALSE 


tmp , 


D; 


A  =  1Dp->buf fer[0] 

B  =  MDp->buffer[l] 

C  =  MDp->buffer[2] 

D  =  MDp-> buffer [3] 

/*  Update  the  message  digest 

ff  (A 

ff  (D 

ff  (C 

ff  (B 

ff(A 

ff  (D 

ff(C 

ff  (B 

ff(A 

ff  (D 

ff(C 

ff  (B 

ff  (A 

ff(D 

ff  (C 

ff(B 

gg(A 

gg(D 

gg<C 

gg<B 

gg(A 

gg(D 

gg(C 

gg(B 

gg(A 

gg(D 

gg(C 

gg(B 

gg(A 

gg(D 

gg(C 

gg(B 

hh(A 

hh(D 

hh(C 

hh(B 

hh(A 

hh(D 

hh(C 

hh(B 

hh(A 

hh(D 

hh(C 

hh(B 

hh(A 

hh(D 

hh(C 


,  B 

C 

D 

0 

fsl), 

,  A 

B 

C 

1 

fs2) ; 

,  D 

A 

B 

2 

fs3); 

,  C 

D 

A 

3 
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C 
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4 
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,  A 

B 
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D 
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C 
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A 

B 
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A 
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D 

A 
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C 

D 

12 
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B 

C 

13 

fs2); 

.  D 

A 

B 

14 

fs3); 

C 

D 

A 

15 

fs4); 

,  B 

C 

0 

0 

gsl); 

.  A 

B 

C 
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A 

B 
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D 

A 
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C 
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B 

C 
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A 

B 
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D 

A 
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C 

D 
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B 

C 

6 
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A 

B 

10 
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D 

A 

14 
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,  B 

C 

D 

3 
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>  A 

B 

C 

7 
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.  D 

A 

B 

11 
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>  c 

D 

A 

15 

gs4 ) ; 

.  B 

,  c 

D 

0 

hsl); 

.  A 

B 

C 

8 

hs2); 

.  D 

.  A 

B 

4 

hs3); 

.  c 

D 

A 

12 

hs4); 

.  B 

,  c 

>  D 

,   2 

hsl); 

.  A 

B 

C 

10 

hs2); 

>  D 

>  A 

>  B 

,   6 
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>  c 

D 

A 

14 
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,  B 

C 

0 

,   1 
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B 

C 
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A 

B 
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,  c 

D 

A 

13 
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,  B 

,  c 

D 

3 
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,  A 

B 

C 

11 
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,  D 

.  A 

B 

,   7 

hs3); 

buffer  */ 
/*  Round 


1  */ 


/*  Round  2  */ 


/*  Round  3  */ 
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hh(  B  ,  C  ,  D  ,  A  ,  15  ,  hs4  )  , 

MDp->buf fer[0]  ••=  A; 

MDp->buf  fer(  1]  f=  B; 

MDp->buf fer[2]  <- -  C; 

MDp->buf fer[3)  f=  D; 
} 

/  *  MDupdatel MDp, X, count ) 

"    Input:  MDp  --  an  MDptr 

**        X  --  a  pointer  to  an  array  of  unsigned  characters. 

'  '         count  --  the  number  of  bits  of  X  to  use. 

11  (if  not  multiple  of  S,  uses  high  bits  of  last  bvte.) 

'  '  (pdate  IDp  using  the  number  of  bits  of  X  given  bv  count. 

1  *  This  is  the  basic  input  routine  for  an  MD4  user. 

'*    The  routine  completes  the  ID  computation  when  count  <  512,  so 

**    every  MD  computation  should  end  with  one  call  to  MDupdate  with  a 

"*  count  less  than  512.   A  call  with  count  0  will  be  ignored  if  the 

*  *  ID  has  already  been  terminated  ( done ! = 0 )  ,  so  an  extra  call  with  count 

**  0  can  be  given  as  a  'courtesy  close'  to  force  termination  if  desired. 

l/ 

void 

MDupdatel MDp.X .count  ) 
MDptr  MDp; 
unsigned  char  *X; 
unsigned  int  count; 

{  unsigned  long  int  i,  tmp,  bit,  byte,  mask; 
unsigned  char  XX[64]; 
unsigned  char  *p; 

/*  return  with  no  error  if  this  is  a  courtesy  close  with  count 
■**  zero  and  MDp->done  is  true. 
*/ 

if  (count  =  =  0  &&  MDp->done)  return; 

/*  check  to  see  if  MD  is  already  done  and  report  error  */ 
if  (MDp->done)  {  print f( " \nError :  MDupdate  MD  already  done.");  return;  } 
/*  Add  count  to  MDp- > count  */ 
tmp  -  count; 
p  =  MDp- > count ; 
whi le  ( tmp ) 
{  tmp  +=  *p; 
*p++  =  tmp; 
tmp  =  tmp  >>  3; 
} 
/*  Process  data  */ 
if  (count  "  512) 

{  /*  Full  block  of  data  to  handle  */ 

MDblockl MDp ,( unsigned  long  int  *)X); 
} 
else  if  (count  >  512)  /*  Check  for  count  too  large  */ 
{  printf 

("\nError:  MDupdate  called  with  illegal  count  value  %d.",count); 
return; 

} 
else  /»  partial  block  --  must  be  last  block  so  finish  up  */ 
{  /*  Find  out  how  many  bytes  and  residual  bits  there  are  */ 
byte  =  count  >  >  3 ; 
bit  =   count  &  7; 

I*   Copy  X  into  XX  since  we  need  to  modify  it  */ 
for  (i=0;i<=byte;i++)   XX[i]  =  X[i]; 
for  (i=byte*l;i<64;i*+)  XX[i]  =  0; 

/*  Add  padding  '1'  bit  and  low-order  zeros  in  last  byte  */ 
mask  =  1  <  <  ( 7  -  bit ) ; 

XX[byte]  =  (XX(byte]  ',    mask)  &  "(  mask  -  1); 
/*  If  room  for  bit  count,  finish  up  with  this  block  */ 
if  (byte  <=  55) 
{  for  (i=0;i<8;i++)  XX[56+i]  =  MDp->count [ i] ; 

MDblock( MDp, ( unsigned  long  int  *)XX); 
} 

else  /*  need  to  do  two  blocks  to  finish  up  */ 
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{  MDblock(MDp, ( unsigned  long  int  *)XX); 
for  (i=0;i<56; i++)  XX[i]  =  0; 
for  ( i  =  0; i<3; i  +  +)   XX[56+i]  =  MDp- >count [ 1 J , 
MDblockfMDp,  ( unsigned  long  int  *)X.\); 
} 

/*  Set  flag  saying  we're  done  with  )"1D  computation  «/ 
MDp->done  =  1; 
} 


"■    End  of  md4.c 
</ 


70 


IX.        LTST   OF   REFERENCES 


Bosen,  Bob,  "Use  of  Message  Authentication  Code  (MAC)  Technology  in  the 
Detection   of  Computer   Viruses",    Enigma   Logic,    1989,    unpublished. 

Chess,  David,  IBM,  VIRUS-L  Digest  Tuesday,  8  May  1990  Volume  3  :  Issue 
90,   moderated    by   Kenneth   R.    van   Wyk. 

Cohen,  Fred,  "Computer  Viruses:  Theory  and  Experiments",  Computer 
Security:  A  Global  Challenge,  J.H.  Finch  and  E.G.  Dougall  (eds),  Elsevier 
Science    Publishers,    B.V.    North   Holland,    1984. 

Davida,  George,  Desmedt,  Yvo,  and  Matt,  Brian,  "Defending  Systems  Against 
Viruses  Through  Cryptographic  Authentication",  Proceedings  1989  IEEE 
Computer  Society  Symposium  on  Security  and  Privacy,  IEEE  Computer 
Society   Press,   Washington,   DC,   1989. 

Denning,  Dorthy,  "Cryptography  and  Data  Security",  Addison-Wesley 
Publishing   Company,    1982. 

McAfee,  John,   McAfee  Associates,   Viral  Characteristics   List  V74,    1991. 

McAfee,  John,   McAfee  Associates,   Implementing   Anti-viral   Programs,    1989. 

McDonald,  Chris,  Information  Systems  Management  Specialist,  ASQNC-TWS-RA, 
VIRUS-L  Digest  Tuesday,  24  Apr  1990  Volume  3  :  Issue  80,  moderated  by 
Kenneth   R.   van   Wyk. 

Merkle,  Ralph,  "A  Fast  Software  One  Way  Hash  Function",  Xerox 
Corporation,    1989,   unpublished. 

Merkle,   Ralph,   "A  Certified   Digital  Signature",   Crypto   1989. 

Mildner,  John,  Code  043,  Naval  Electronic  Systems  Security  Engineering 
Center,  Washington,  DC,   telephone  conversation,   12   March    1991. 

Rivest,   Ron,   RSA  Data  Security,  February   1990,   private  communication. 

Seberry,  Jennifer  and  Pieprzyk,  Josef,  "Cryptography:  An  Introduction  To 
Computer   Security",   Prentice-Hall,   Australia,   1989. 

Skulason,  Fridrik,  Technical  Editor,  Virus  Bulletin  (UK),  University  of 
Iceland,  VIRUS-L  Digest  Friday,  9  Feb  1990  Volume  3  :  Issue  35, 
moderated   by   Kenneth   R.   van  Wyk. 


71 


Skulason,  Fridrik,  Technical  Editor  of  the  Virus  Bulletin  (UK),  University 
of  Iceland,  VIRUS-L  Digest  Tuesday,  27  Mar  1990  Volume  3  :  Issue  64, 
moderated   by   Kenneth  R.    van  Wyk. 

Skulason,  Fridrik,  Technical  Editor  of  the  Virus  Bulletin  (UK),  University 
of  Iceland,  VIRUS-L  Digest  Wednesday,  9  May  1990  Volume  3  :  Issue  91, 
moderated    by   Kenneth   R.    van   Wyk. 

Skulason,  Fridrik,  Technical  Editor  of  the  Virus  Bulletin  (UK),  University 
of  Iceland,  as  translated  by  Vesselin  Bontchev,  VIRUS-L  Digest  Friday,  18 
May    1990        Volume   3   :    Issue   97,   moderated   by   Kenneth   R.   van   Wyk. 

Skulason,  Fridrik,  Technical  Editor  of  the  Virus  Bulletin  (UK),  University 
of  Iceland,  VIRUS-L  Digest  Monday  7  May  1990  Volume  3  :  Issue  89, 
moderated   by   Kenneth   R.   van   Wyk. 

Skulason,  Fridrik,  Technical  Editor  of  the  Virus  Bulletin  (UK),  University 
of  Iceland,  VIRUS-L  Digest  Monday,  29  Jan  1990  Volume  3  :  Issue  24, 
moderated   by   Kenneth   R.   van  Wyk. 

Spafford,  Gene,  S  ?tware  Engineering  Center,  Purdue  University,  VIRUS-L 
Digest  Friday,  12  Jan  1990  Volume  3  :  Issue  10,  moderated  by  Kenneth  R. 
van   Wyk. 

Swimmer,  Morton,  Virus  Test  Center,  University  of  Hamburg,  VIRUS-L  Digest 
Monday,  21  May  1990  Volume  3  :  Issue  99,  moderated  by  Kenneth  R.  van 
Wyk. 

Tannenbaum,  Andrew  S.,  "Computer  Networks",  Prentice-Hall,  Englewood 
Cliffs,  New  Jersey,   1989. 


72 


INITIAL    DISTRIBUTION   LIST 


1.  Defense   Technical  Information   Center 
Cameron   Station 

Alexandria,  Virginia  22304-6145 

2.  Commanding  Officer 

Naval   Electronic   Systems   Security   Engineering   Center 

Code  043 

3801   Nebraska  Ave  NW 

Washington,   DC   20393-5270 

3.  Dr.   Norman   F.   Schneidewind 

Code  AS-SS 

Naval   Postgraduate   School 

Monterey,  California  93943-5002 

4.  Dr.   Tung   X.    Bui 

Code  AS-TN 

Naval   Postgraduate   School 

Monterey,  California  93943-5002 

5.  Library,  Code  52 

Naval   Postgraduate   School 
Monterey,  California  93943-5002 


73 


Thesis 

L31723  LaVenture 
Ctl  Software  and  the 

virus  threat. 


Thesis 

L31723  LaVenture 
c.l       Software  and  the 
virus  threat. 


